From miguel.deval at gmail.com  Tue Jun  1 07:35:08 2010
From: miguel.deval at gmail.com (Miguel de Val Borro)
Date: Mon, 31 May 2010 23:35:08 +0200
Subject: scp port on remote hosts
Message-ID: <20100531213508.GA2499@HssO>

Hello,

I would like to specify ports on both hosts to copy files between two
remote computeres. Is there any way to do this with scp? The -P flag
seems to apply to the port on the second host only.

Regards,
Miguel

From peter at stuge.se  Tue Jun  1 11:15:48 2010
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Jun 2010 03:15:48 +0200
Subject: scp port on remote hosts
In-Reply-To: <20100531213508.GA2499@HssO>
References: <20100531213508.GA2499@HssO>
Message-ID: <20100601011548.3270.qmail@stuge.se>

Miguel de Val Borro wrote:
> I would like to specify ports on both hosts to copy files between two
> remote computeres. Is there any way to do this with scp?

I don't think so. Suggest you use a host alias that you can configure
in .ssh/config on the remote host. Use hostname, hostkeyalias and
port.


//Peter

From dgbaley27 at verizon.net  Tue Jun  1 12:10:07 2010
From: dgbaley27 at verizon.net (Matthew Monaco)
Date: Mon, 31 May 2010 22:10:07 -0400
Subject: scp port on remote hosts
In-Reply-To: <20100531213508.GA2499@HssO>
References: <20100531213508.GA2499@HssO>
Message-ID: <4C046BFF.2060107@verizon.net>

On 05/31/2010 05:35 PM, Miguel de Val Borro wrote:
> Hello,
>
> I would like to specify ports on both hosts to copy files between two
> remote computeres. Is there any way to do this with scp? The -P flag
> seems to apply to the port on the second host only.
>
> Regards,
> Miguel
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

The syntax -P #[,#] would be nice for this.


From brakeb at gmail.com  Tue Jun  1 23:17:52 2010
From: brakeb at gmail.com (Bryan)
Date: Tue, 1 Jun 2010 08:17:52 -0500
Subject: QoS marking for Openssh (review wanted)
In-Reply-To: <4BFD8DB4.1090000@redfish-solutions.com>
References: <4B931780.9010200@employees.org>
	<alpine.BSO.2.00.1003091052010.19690@fuyu.mindrot.org> 
	<4B96EB48.3030204@employees.org>
	<alpine.BSO.2.00.1003101147470.23195@fuyu.mindrot.org> 
	<4B96F506.7060106@employees.org>
	<alpine.BSO.2.00.1003101234020.23195@fuyu.mindrot.org> 
	<4BAA5DD3.6020004@redfish-solutions.com>
	<4BDA3708.1040307@redfish-solutions.com> 
	<alpine.BSO.2.00.1004301202010.30722@fuyu.mindrot.org>
	<4BFD8DB4.1090000@redfish-solutions.com>
Message-ID: <AANLkTil93veVFxJaHdNxpOmZQ-qsSJd7Qxt_A8sD0TvX@mail.gmail.com>

On Wed, May 26, 2010 at 16:08, Philip A. Prindeville
<philipp_subx at redfish-solutions.com> wrote:
> Still being patient... ?do we have an estimate on when you might get to it?
>
> Thanks.
>

This is not a project that you can manage...  If it's important
enough, they'll get to it... if you need it sooner, you can pay them
vast sums of money to drop everything else to pacify you, or you can
code it up yourself...

From alex at alex.org.uk  Tue Jun  1 21:40:28 2010
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 01 Jun 2010 07:40:28 -0400
Subject: scp port on remote hosts
In-Reply-To: <4C046BFF.2060107@verizon.net>
References: <20100531213508.GA2499@HssO> <4C046BFF.2060107@verizon.net>
Message-ID: <B038B6E929740AF67B449D2D@nimrod.local>



--On 31 May 2010 22:10:07 -0400 Matthew Monaco <dgbaley27 at verizon.net> 
wrote:

>> I would like to specify ports on both hosts to copy files between two
>> remote computeres. Is there any way to do this with scp? The -P flag
>> seems to apply to the port on the second host only.
>>
>> Regards,
>> Miguel
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>
> The syntax -P #[,#] would be nice for this.

Actually the syntax
  scp:source.example.com:1234:source/file dest.example.com:3456:dest/file

would be even more useful. I can only suppose this is not implemented
as there is a theoretically possibility the file is called
"1234:source/file", though this could be specified by quoting, inserting
"./" or whatever.

-- 
Alex Bligh

From philipp_subx at redfish-solutions.com  Wed Jun  2 01:17:09 2010
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Tue, 01 Jun 2010 08:17:09 -0700
Subject: QoS marking for Openssh (review wanted)
In-Reply-To: <AANLkTil93veVFxJaHdNxpOmZQ-qsSJd7Qxt_A8sD0TvX@mail.gmail.com>
References: <4B931780.9010200@employees.org>
	<alpine.BSO.2.00.1003091052010.19690@fuyu.mindrot.org>
	<4B96EB48.3030204@employees.org>
	<alpine.BSO.2.00.1003101147470.23195@fuyu.mindrot.org>
	<4B96F506.7060106@employees.org>
	<alpine.BSO.2.00.1003101234020.23195@fuyu.mindrot.org>
	<4BAA5DD3.6020004@redfish-solutions.com>
	<4BDA3708.1040307@redfish-solutions.com>
	<alpine.BSO.2.00.1004301202010.30722@fuyu.mindrot.org>
	<4BFD8DB4.1090000@redfish-solutions.com>
	<AANLkTil93veVFxJaHdNxpOmZQ-qsSJd7Qxt_A8sD0TvX@mail.gmail.com>
Message-ID: <4C052475.2040100@redfish-solutions.com>

On 6/1/10 6:17 AM, Bryan wrote:
> On Wed, May 26, 2010 at 16:08, Philip A. Prindeville
> <philipp_subx at redfish-solutions.com>  wrote:
>    
>> Still being patient...  do we have an estimate on when you might get to it?
>>
>> Thanks.
>>
>>      
> This is not a project that you can manage...  If it's important
> enough, they'll get to it... if you need it sooner, you can pay them
> vast sums of money to drop everything else to pacify you, or you can
> code it up yourself...
>    

Are we talking about the same thing?

The "review wanted" in the subject line refers to a review of patch that 
I already did, indeed, "code up myself" and I'm just waiting on a review 
of it.

So when you say "code it up yourself"... I'm not quite sure what you're 
referring to that I should code that I haven't already done.

-Philip


From brakeb at gmail.com  Wed Jun  2 01:19:58 2010
From: brakeb at gmail.com (Bryan)
Date: Tue, 1 Jun 2010 10:19:58 -0500
Subject: QoS marking for Openssh (review wanted)
In-Reply-To: <4C052475.2040100@redfish-solutions.com>
References: <4B931780.9010200@employees.org>
	<alpine.BSO.2.00.1003091052010.19690@fuyu.mindrot.org> 
	<4B96EB48.3030204@employees.org>
	<alpine.BSO.2.00.1003101147470.23195@fuyu.mindrot.org> 
	<4B96F506.7060106@employees.org>
	<alpine.BSO.2.00.1003101234020.23195@fuyu.mindrot.org> 
	<4BAA5DD3.6020004@redfish-solutions.com>
	<4BDA3708.1040307@redfish-solutions.com> 
	<alpine.BSO.2.00.1004301202010.30722@fuyu.mindrot.org>
	<4BFD8DB4.1090000@redfish-solutions.com> 
	<AANLkTil93veVFxJaHdNxpOmZQ-qsSJd7Qxt_A8sD0TvX@mail.gmail.com> 
	<4C052475.2040100@redfish-solutions.com>
Message-ID: <AANLkTikpqkz1g7TXOuav_culwsFgadZnCs_172UA3Spk@mail.gmail.com>

I stand corrected...  It's too early in the morning...  sorry for the noise...

On Tue, Jun 1, 2010 at 10:17, Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:
> On 6/1/10 6:17 AM, Bryan wrote:
>>
>> On Wed, May 26, 2010 at 16:08, Philip A. Prindeville
>> <philipp_subx at redfish-solutions.com> ?wrote:
>>
>>>
>>> Still being patient... ?do we have an estimate on when you might get to
>>> it?
>>>
>>> Thanks.
>>>
>>>
>>
>> This is not a project that you can manage... ?If it's important
>> enough, they'll get to it... if you need it sooner, you can pay them
>> vast sums of money to drop everything else to pacify you, or you can
>> code it up yourself...
>>
>
> Are we talking about the same thing?
>
> The "review wanted" in the subject line refers to a review of patch that I
> already did, indeed, "code up myself" and I'm just waiting on a review of
> it.
>
> So when you say "code it up yourself"... I'm not quite sure what you're
> referring to that I should code that I haven't already done.
>
> -Philip
>
>

From Phillip.Wu at lpma.nsw.gov.au  Wed Jun  2 13:16:21 2010
From: Phillip.Wu at lpma.nsw.gov.au (Phillip Wu)
Date: Wed, 2 Jun 2010 13:16:21 +1000
Subject: openssh sftp fails to start a session
Message-ID: <137CA4FE5CCDB7449ED3CD4445077AC304EAD32F60@SRV-QS-MAIL6.lands.nsw>

Hi,

I am having trouble running sftp from the openssh package openssh-5.5p1. There seems to
be an authentication problem.

This is what happens:
$ sftp -o "Port 2022" testu at localhost
testu at localhost's password:
Connection closed

QUESTION:
Can someone spot the problem please? How do I fix this?

FURTHER INFORMATION
I can run openssh's ssh:
$ ./ssh -p 2022 testu at localhost
testu at localhost's password:
Last login: Wed Jun  2 12:55:01 2010 from localhost.localdomain

I have run sshd in debug mode and the output is at the bottom of this email.

There is nothing wrong with testu's password as I can run sftp (the standard one on Redhat) OK:
$ sftp testu at localhost
Connecting to localhost...
testu at localhost's password:
sftp>

I am compiling and running openssh on Redhat 4.

I compile it with:
./configure --prefix=/home/myuser/openssh --sysconfdir=/home/myuser/openssh/ssh --enable-pam --disable-privsep

The sshd_config file is:
Port 2022
PasswordAuthentication yes
ChallengeResponseAuthentication yes
X11Forwarding yes
Protocol 2

The pam config it is using is /etc/pam.d/sshd:
#%PAM-1.0
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
session    required     pam_loginuid.so

The trace does say that it cannot stat /home/myuser/openssh/libexec/sftp-server but the executable has
r-x for "others" and that goes for all directories above it.



=============================================================================================
debug2: load_server_config: filename /home/myuser/openssh/ssh/sshd_config
debug2: load_server_config: done config len = 300
debug2: parse_server_config: config /home/myuser/openssh/ssh/sshd_config len 300
debug3: /home/myuser/openssh/ssh/sshd_config:13 setting Port 2022
debug3: /home/myuser/openssh/ssh/sshd_config:19 setting Protocol 2
debug3: /home/myuser/openssh/ssh/sshd_config:33 setting SyslogFacility AUTH
debug3: /home/myuser/openssh/ssh/sshd_config:34 setting LogLevel INFO
debug3: /home/myuser/openssh/ssh/sshd_config:59 setting PasswordAuthentication yes
debug3: /home/myuser/openssh/ssh/sshd_config:63 setting ChallengeResponseAuthentication yes
debug3: /home/myuser/openssh/ssh/sshd_config:90 setting X11Forwarding yes
debug3: /home/myuser/openssh/ssh/sshd_config:112 setting Subsystem sftp    /home/myuser/openssh/libexec/sftp-server
debug1: sshd version OpenSSH_5.5p1
debug3: Not a RSA1 key file /home/myuser/openssh/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /home/myuser/openssh/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/home/myuser/openssh/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-d'
debug1: rexec_argv[3]='-d'
debug1: rexec_argv[4]='-f'
debug1: rexec_argv[5]='/home/myuser/openssh/ssh/sshd_config'
debug3: oom_adjust_setup
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2022 on 0.0.0.0.
Server listening on 0.0.0.0 port 2022.
socket: Address family not supported by protocol
debug3: fd 4 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 7 config len 300
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 34117
debug1: Client protocol version 2.0; client software version OpenSSH_5.5
debug1: match: OpenSSH_5.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
debug2: fd 3 setting O_NONBLOCK
debug3: privsep user:group 74:74
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: Network child is on pid 18299
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-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: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss
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: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug3: mm_request_send entering: type 0
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 1024 8192
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 121/256
debug2: bits set: 491/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 525/1024
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
debug3: mm_answer_sign: signature 0x88d08b0(271)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user testu service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug3: Trying to reverse map address 127.0.0.1.
debug2: parse_server_config: config reprocess config len 300
debug3: auth_shadow_acctexpired: today 14762 sp_expire -1 days left -14763
debug3: account expiration disabled
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for testu
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for testu from 127.0.0.1 port 34117 ssh2
debug3: mm_request_receive entering
debug3: mm_auth_password: user not authenticated
debug1: userauth-request for user testu service ssh-connection method publickey
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x88c7648
debug1: temporarily_use_uid: 502/502 (e=0/0)
debug1: trying public key file /home/testu/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 502/502 (e=0/0)
debug1: trying public key file /home/testu/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for testu from 127.0.0.1 port 34117 ssh2
debug3: mm_answer_keyallowed: key 0x88c7648 is not allowed
debug3: mm_request_send entering: type 21
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug1: userauth-request for user testu service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=testu devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
debug1: userauth-request for user testu service ssh-connection method password
debug1: attempt 3 failures 2
debug2: input_userauth_request: try method password
debug3: mm_auth_password entering
debug3: mm_request_send entering: type 10
debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: auth_shadow_pwexpired: today 14762 sp_lstchg 14714 sp_max 99999
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
Accepted password for testu from 127.0.0.1 port 34117 ssh2
debug1: monitor_child_preauth: testu has been authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_auth_password: user authenticated
debug3: mm_send_keystate: Sending new keys: 0x88d0860 0x88c79d0
debug3: mm_newkeys_to_blob: converting 0x88d0860
debug3: mm_newkeys_to_blob: converting 0x88c79d0
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 0x88d0e50(118)
debug2: mac_setup: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x88d0e50(118)
debug2: mac_setup: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug1: permanently_set_uid: 502/502
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug3: session_unused: session id 0 unused
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0
User child is on pid 18300
debug3: mm_request_receive entering
debug1: server_input_channel_req: channel 0 request subsystem reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
subsystem request for sftp
debug1: subsystem: cannot stat /home/myuser/openssh/libexec/sftp-server: Permission denied
debug1: subsystem: exec() /home/myuser/openssh/libexec/sftp-server
debug2: fd 3 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug2: fd 8 setting O_NONBLOCK
debug2: channel 0: read<=0 rfd 9 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug2: notify_done: reading
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 18301
debug1: session_exit_message: session 0 channel 0 pid 18301
debug2: channel 0: request exit-signal confirm 0
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: send eow
debug2: channel 0: output open -> closed
debug2: channel 0: send close
debug3: channel 0: will not send data after close
debug2: channel 0: rcvd close
Received disconnect from 127.0.0.1: 11: disconnected by user
debug1: do_cleanup
debug1: do_cleanup

***************************************************************
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Land and Property Management Authority. This email message has been swept by MIMEsweeper for the presence of computer viruses.
***************************************************************
Please consider the environment before printing this email.

From tim at multitalents.net  Wed Jun  2 14:57:13 2010
From: tim at multitalents.net (Tim Rice)
Date: Tue, 1 Jun 2010 21:57:13 -0700 (PDT)
Subject: openssh sftp fails to start a session
In-Reply-To: <137CA4FE5CCDB7449ED3CD4445077AC304EAD32F60@SRV-QS-MAIL6.lands.nsw>
References: <137CA4FE5CCDB7449ED3CD4445077AC304EAD32F60@SRV-QS-MAIL6.lands.nsw>
Message-ID: <Pine.UW2.4.64.1006012153100.6918@server01.int.multitalents.net>

On Wed, 2 Jun 2010, Phillip Wu wrote:

> Hi,
> 
> I am having trouble running sftp from the openssh package openssh-5.5p1. There seems to
> be an authentication problem.
> 
> This is what happens:
> $ sftp -o "Port 2022" testu at localhost
> testu at localhost's password:
> Connection closed
> 
> QUESTION:
> Can someone spot the problem please? How do I fix this?
> 
[snip]
> subsystem request for sftp
> debug1: subsystem: cannot stat /home/myuser/openssh/libexec/sftp-server: Permission denied

looks like a permissions problem.
Show us the output of
ls -ld / /home /home/myuser /home/myuser/openssh /home/myuser/openssh/libexec
ls -ld /home/myuser/openssh/libexec/sftp-server


-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net



From Phillip.Wu at lpma.nsw.gov.au  Wed Jun  2 16:37:19 2010
From: Phillip.Wu at lpma.nsw.gov.au (Phillip Wu)
Date: Wed, 2 Jun 2010 16:37:19 +1000
Subject: openssh sftp fails to start a session - oops
In-Reply-To: <Pine.UW2.4.64.1006012153100.6918@server01.int.multitalents.net>
References: <137CA4FE5CCDB7449ED3CD4445077AC304EAD32F60@SRV-QS-MAIL6.lands.nsw>
	<Pine.UW2.4.64.1006012153100.6918@server01.int.multitalents.net>
Message-ID: <137CA4FE5CCDB7449ED3CD4445077AC304EAD32F66@SRV-QS-MAIL6.lands.nsw>

Sorry about the original query - it was as Tim says the /home/myuser directory was secured incorrectly and had permissions:
drwx------

As soon as I changed the permissions all was OK.

Thanks to Tim.................

-----Original Message-----
From: openssh-unix-dev-bounces+phillip.wu=lpma.nsw.gov.au at mindrot.org [mailto:openssh-unix-dev-bounces+phillip.wu=lpma.nsw.gov.au at mindrot.org] On Behalf Of Tim Rice
Sent: Wednesday, 2 June 2010 2:57 PM
To: openssh-unix-dev at mindrot.org
Subject: Re: openssh sftp fails to start a session

On Wed, 2 Jun 2010, Phillip Wu wrote:

> Hi,
> 
> I am having trouble running sftp from the openssh package openssh-5.5p1. There seems to
> be an authentication problem.
> 
> This is what happens:
> $ sftp -o "Port 2022" testu at localhost
> testu at localhost's password:
> Connection closed
> 
> QUESTION:
> Can someone spot the problem please? How do I fix this?
> 
[snip]
> subsystem request for sftp
> debug1: subsystem: cannot stat /home/myuser/openssh/libexec/sftp-server: Permission denied

looks like a permissions problem.
Show us the output of
ls -ld / /home /home/myuser /home/myuser/openssh /home/myuser/openssh/libexec
ls -ld /home/myuser/openssh/libexec/sftp-server


-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net


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

***************************************************************
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Land and Property Management Authority. This email message has been swept by MIMEsweeper for the presence of computer viruses.
***************************************************************
Please consider the environment before printing this email.

From alex at alex.org.uk  Wed Jun  2 22:49:12 2010
From: alex at alex.org.uk (Alex Bligh)
Date: Wed, 02 Jun 2010 08:49:12 -0400
Subject: known_hosts
Message-ID: <54F69722A9AEC15BF9F3A54E@nimrod.local>

Is there a good reason why known_hosts stores the address of the server
but not the port? This is annoying when one host is running more than
one instance of openssh with different ports and different keys, or
(less tractably) when a NAT in front of multiple hosts multiplexes
which host is connected to by port number. I see no immediate security
implication in fixing this, but am I missing something?

-- 
Alex Bligh

From mouring at eviladmin.org  Thu Jun  3 00:03:53 2010
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 2 Jun 2010 09:03:53 -0500
Subject: known_hosts
In-Reply-To: <54F69722A9AEC15BF9F3A54E@nimrod.local>
References: <54F69722A9AEC15BF9F3A54E@nimrod.local>
Message-ID: <A9AB19FB-F5E9-4556-B4A2-8A4548663784@eviladmin.org>


$ man sshd
[..]
SSH_KNOWN_HOSTS FILE FORMAT
     The /etc/ssh_known_hosts and ~/.ssh/known_hosts files contain host public keys for all known hosts.  The global file should be
     prepared by the administrator (optional), and the per-user file is maintained automatically: whenever the user connects from an
     unknown host, its key is added to the per-user file.

     Each line in these files contains the following fields: hostnames, bits, exponent, modulus, comment.  The fields are separated by
     spaces.

     Hostnames is a comma-separated list of patterns (`*' and `?' act as wildcards); each pattern in turn is matched against the
     canonical host name (when authenticating a client) or against the user-supplied name (when authenticating a server).  A pattern
     may also be preceded by `!' to indicate negation: if the host name matches a negated pattern, it is not accepted (by that line)
     even if it matched another pattern on the line.  A hostname or address may optionally be enclosed within `[' and `]' brackets
     then followed by `:' and a non-standard port number.


.. This has been in since 2006.  Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=910

- Ben

On Jun 2, 2010, at 7:49 AM, Alex Bligh wrote:

> Is there a good reason why known_hosts stores the address of the server
> but not the port? This is annoying when one host is running more than
> one instance of openssh with different ports and different keys, or
> (less tractably) when a NAT in front of multiple hosts multiplexes
> which host is connected to by port number. I see no immediate security
> implication in fixing this, but am I missing something?
> 
> -- 
> Alex Bligh
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From alex at alex.org.uk  Thu Jun  3 01:20:35 2010
From: alex at alex.org.uk (Alex Bligh)
Date: Wed, 02 Jun 2010 11:20:35 -0400
Subject: known_hosts
In-Reply-To: <A9AB19FB-F5E9-4556-B4A2-8A4548663784@eviladmin.org>
References: <54F69722A9AEC15BF9F3A54E@nimrod.local>
	<A9AB19FB-F5E9-4556-B4A2-8A4548663784@eviladmin.org>
Message-ID: <206FB7C041FDC0A5867B818B@nimrod.local>



--On 2 June 2010 09:03:53 -0500 Ben Lindstrom <mouring at eviladmin.org> wrote:

> .. This has been in since 2006.  Bug:
> https://bugzilla.mindrot.org/show_bug.cgi?id=910

That's completely bizarre. I could have sworn it was not adding the
port number in this morning. It is now...

-- 
Alex Bligh

From imorgan at nas.nasa.gov  Sat Jun  5 07:22:03 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 4 Jun 2010 14:22:03 -0700
Subject: Hostbased authentication with certificates
Message-ID: <20100604212203.GE19561@linux55.nas.nasa.gov>

Greetings,

For those interested in using certificates with hostbased
authentication, I have just submitted an enhancement request[1] to the
OpenSSH bugzilla site with a preliminary patch that adds support for
this.

Despite the fact that hostbased authentication is, by default, disabled
for both the client and server, there are environments where hostbased
authentication can be very useful. One such example would be large
compute clusters. In such environments, being able to use certificates
would ease the management of the ssh_known_hosts file and simplify the
process of adding additional compute nodes or replacing existing host
keys.

The intent of the patch is to extend certificate support to hostbased
authentication in a fairly transparent manner. If hostbased
authentication is enabled and the client has a host cert, it will be
included in the authentication message. And if the server has an
appropriate @cert-authority entry in the ssh_known_hosts file, the
request can be authenticated with the usual caveats and conditions
applied to hostbased authentication.

If the certificate has a non-empty list of principals, the resolved name
(or possibly the canonical hostname supplied in the authentication
message) will be checked against the list of principals. Thus, the list
of principals should include the fully-qualified name of the client
host.

The ordering of hostbased authentication attempts has been chosen to
prefer certificates if they are available. Once the client has tried any
available certificates without success, it will then try unadorned host
keys in the usual order (DSA followed by RSA). This means that in a
worst-case scenario four hostbased authentication attempts may be tried.
However, it is expected that most sites will only deploy one host
certificate type and thus the maximum number of attempts under such
circumstances would only be three.

The patch has only undergone limited testing at this point, but it
appears to be functional. It has been tested both with and without
ssh-keysign and some (but not all) error cases have been tested.

Feel free to provide input to bz#1776 or as a response to this email if
you prefer.


Regards,

-- 
Iain Morgan

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=1776

From imorgan at nas.nasa.gov  Sat Jun  5 08:12:28 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 4 Jun 2010 15:12:28 -0700
Subject: Question about host certificates
In-Reply-To: <alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
Message-ID: <20100604221228.GA5299@linux55.nas.nasa.gov>

On Thu, Mar 18, 2010 at 17:55:02 -0500, Damien Miller wrote:
> On Thu, 18 Mar 2010, Iain Morgan wrote:
> 
> > Hi,
> > 
> > I'm experimenting with host certificates in 5.4p1 and seem to have hit a
> > usability issue. I've generated a host certificate, added the
> > HostCertificate option to the sshd_config and restarted sshd. I've
> > replaced the system's ssh_known_hosts file with one that has a single
> > entry of the form:
> > 
> > @cert-authority *.example.domain ssh-rsa ...
> > 
> > This works provided that I use the host's FQDn when I ssh to it. If I
> > use an unqualified name, the connection is made but the certificate
> > verification fails. I suppose an entry like
> > 
> > @cert-authority *,*.example.domain ssh-rsa ...
> > 
> > would work, but it doesn't seem prudent. How are you supposed to specify
> > that the cert-authority is for the local domain? It seem like the name
> > of the target host should be resolved to a FQDN prior to checking
> > whether or not the cert-authority is applicable.
> > 
> > I know this issue _could_ be addressed by listing the unqualified name
> > as well as the globbed domain name, but that doesn't seem like a very
> > scalable solution.
> 
> Yes, it would be good if we could get feedback from the resolver as to
> which effective FQDN was used for resolution so we could canonicalise the
> name without an unsafe reverse lookup step. I haven't yet looked into
> how to do this.
> 
> Two more alternatives: have some way of expressing wildcards that match
> only unqualified domains (e.g. rtr-syd-*[^.]*) or allow CIDR address
> matching in the host list so you could specify something like:
> 
> @cert-authority 10.0.0.0/8 ssh-rsa ...
> 
> Though we would need to think through the consequences first.
> 
> -d

Hi Damine,

If possible, I would prefer hostname or CIDR support. In either case, it
might be worthwhile to use addr_match_list() instead of match_hostname()
to handle the (admittedly rare) case where an explicit IP address is
used on the command-line.

Yet another approach occurred to me recently. It would not be a complete
solution but would have the virtue of being simple and could address
(for the most part) environments such as compute clusters: Generalize
the HostName directive. In particular, add support for a %h macro. That
would allow something like this in ~/.ssh/config:

Host foo bar baz quux
	HostName	%h.example.com

In cases where the list of unqualified hostnames can easily be
enumerated or match a convenient pattern, this could be a solution.

Regards,

-- 
Iain Morgan

From imorgan at nas.nasa.gov  Sat Jun  5 08:52:47 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 4 Jun 2010 15:52:47 -0700
Subject: Question about host certificates
In-Reply-To: <20100604221228.GA5299@linux55.nas.nasa.gov>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
Message-ID: <20100604225247.GF19561@linux55.nas.nasa.gov>

On Fri, Jun 04, 2010 at 17:12:28 -0500, Iain Morgan wrote:
> On Thu, Mar 18, 2010 at 17:55:02 -0500, Damien Miller wrote:
> > On Thu, 18 Mar 2010, Iain Morgan wrote:
> > 
> > > Hi,
> > > 
> > > I'm experimenting with host certificates in 5.4p1 and seem to have hit a
> > > usability issue. I've generated a host certificate, added the
> > > HostCertificate option to the sshd_config and restarted sshd. I've
> > > replaced the system's ssh_known_hosts file with one that has a single
> > > entry of the form:
> > > 
> > > @cert-authority *.example.domain ssh-rsa ...
> > > 
> > > This works provided that I use the host's FQDn when I ssh to it. If I
> > > use an unqualified name, the connection is made but the certificate
> > > verification fails. I suppose an entry like
> > > 
> > > @cert-authority *,*.example.domain ssh-rsa ...
> > > 
> > > would work, but it doesn't seem prudent. How are you supposed to specify
> > > that the cert-authority is for the local domain? It seem like the name
> > > of the target host should be resolved to a FQDN prior to checking
> > > whether or not the cert-authority is applicable.
> > > 
> > > I know this issue _could_ be addressed by listing the unqualified name
> > > as well as the globbed domain name, but that doesn't seem like a very
> > > scalable solution.
> > 
> > Yes, it would be good if we could get feedback from the resolver as to
> > which effective FQDN was used for resolution so we could canonicalise the
> > name without an unsafe reverse lookup step. I haven't yet looked into
> > how to do this.
> > 
> > Two more alternatives: have some way of expressing wildcards that match
> > only unqualified domains (e.g. rtr-syd-*[^.]*) or allow CIDR address
> > matching in the host list so you could specify something like:
> > 
> > @cert-authority 10.0.0.0/8 ssh-rsa ...
> > 
> > Though we would need to think through the consequences first.
> > 
> > -d
> 
> Hi Damine,
> 
> If possible, I would prefer hostname or CIDR support. In either case, it
> might be worthwhile to use addr_match_list() instead of match_hostname()
> to handle the (admittedly rare) case where an explicit IP address is
> used on the command-line.
> 
> Yet another approach occurred to me recently. It would not be a complete
> solution but would have the virtue of being simple and could address
> (for the most part) environments such as compute clusters: Generalize
> the HostName directive. In particular, add support for a %h macro. That
> would allow something like this in ~/.ssh/config:
> 
> Host foo bar baz quux
> 	HostName	%h.example.com
> 
> In cases where the list of unqualified hostnames can easily be
> enumerated or match a convenient pattern, this could be a solution.
> 
> Regards,
> 

Hmm, after some further reflection I suspect that HostKeyAlias would be
a better choice for this than HostName.

-- 
Iain Morgan

From Naitik.Dani at netapp.com  Tue Jun  8 08:04:09 2010
From: Naitik.Dani at netapp.com (Dani, Naitik)
Date: Mon, 7 Jun 2010 18:04:09 -0400
Subject: X509 based certificate authentication in OpenSSH
Message-ID: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>

Hello,

I would like to know whether OpenSSH supports x509 certificate based
authentication.
It looks like OpenSSH has dependency on OpenSSL so does this mean that
OpeSSH also supports x509 certificate based authentication.

If it does support, can you please point me to the necessary
documentation. 

Thanks
Naitik 

From imorgan at nas.nasa.gov  Tue Jun  8 09:22:52 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 7 Jun 2010 16:22:52 -0700
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
Message-ID: <20100607232252.GG19561@linux55.nas.nasa.gov>

On Mon, Jun 07, 2010 at 17:04:09 -0500, Dani, Naitik wrote:
> Hello,
> 
> I would like to know whether OpenSSH supports x509 certificate based
> authentication.

No, although Roumen Petrov maintains a patch that adds such support.

> It looks like OpenSSH has dependency on OpenSSL so does this mean that
> OpeSSH also supports x509 certificate based authentication.

No, OpenSSH just uses the low-level cryptographic algorithms from
OpenSSL.

> 
> If it does support, can you please point me to the necessary
> documentation. 
> 

The developers have maintained a stance that the complexity of X.509
certificates introduces an unacceptable attack surface for sshd.
Instead, they have recently implemented an alternative certificate
format which is much simpler to parse and thus introduces less risk. See
the various man pages in OpenSSH 5.5 for more information.

-- 
Iain Morgan

From Naitik.Dani at netapp.com  Wed Jun  9 05:54:57 2010
From: Naitik.Dani at netapp.com (Dani, Naitik)
Date: Tue, 8 Jun 2010 15:54:57 -0400
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <20100607232252.GG19561@linux55.nas.nasa.gov>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
Message-ID: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A6593@RTPMVEXC1-PRD.hq.netapp.com>

Thanks for your responses. They really helped me in understanding. 

Following are the steps I did to install a self-signed certificate:
1) client: ssh-keygen -f ca_rsa
2) ssh-keygen -s ca_rsa -I 0 -n USER1 ca_rsa.pub
3) Copied the ca_rsa-cert.pub to ~/.ssh/authorized_keys file on the
servers.
4) ssh USER1 [at] server

Did I miss anything in the above steps?

Qestions:
1) How does CA-signed certificate work in SSH?
2) Does Verisgin and other companies issue such kind of certificates?
3) What kind of input do such companies require in order to generate a
CA-signed certificate.
   For example, SSL generates CSR and that CSR is sent out to these
companies to generate CA-signed certificate.
3) What are the different options I need to use to make step 1 working?

Thanks in advance.

Naitik Dani
MTS
GX Infrastructure HQ

NetApp
724-741-5153 Direct
Naitik.Dani at netapp.com
www.netapp.com



 

> -----Original Message-----
> From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
> Sent: Monday, June 07, 2010 19:23
> To: Dani, Naitik
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: X509 based certificate authentication in OpenSSH
> 
> On Mon, Jun 07, 2010 at 17:04:09 -0500, Dani, Naitik wrote:
> > Hello,
> > 
> > I would like to know whether OpenSSH supports x509 certificate based
> > authentication.
> 
> No, although Roumen Petrov maintains a patch that adds such support.
> 
> > It looks like OpenSSH has dependency on OpenSSL so does 
> this mean that
> > OpeSSH also supports x509 certificate based authentication.
> 
> No, OpenSSH just uses the low-level cryptographic algorithms from
> OpenSSL.
> 
> > 
> > If it does support, can you please point me to the necessary
> > documentation. 
> > 
> 
> The developers have maintained a stance that the complexity of X.509
> certificates introduces an unacceptable attack surface for sshd.
> Instead, they have recently implemented an alternative certificate
> format which is much simpler to parse and thus introduces 
> less risk. See
> the various man pages in OpenSSH 5.5 for more information.
> 
> -- 
> Iain Morgan
> 

From jeremy at nickurak.ca  Wed Jun  9 04:58:51 2010
From: jeremy at nickurak.ca (Jeremy Nickurak)
Date: Tue, 8 Jun 2010 12:58:51 -0600
Subject: OpenSSH with "resumable" functionality
Message-ID: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>

I just stumbled across this thread on openssh-dev...

Is there anywhere to track progress on this issue? It'd be a fantastic
feature that would fix all sorts of problems I deal with regularly.

You may also be interested in an article "Design and Implementation of a
Mobile SSH Protocol", if you haven't seen it, since that team implemented
(afaict) the same feature, whether or not it's related to the existing
implementation...

The article attribution lists:

I-Hsuan Huang?, Wei-Jin Tzeng?, Szu-Wei Wang?, and Cheng-Zen Yang?
Department of Computer Science and Engineering
Yuan Ze University, Chungli, Taiwan, R.O.C.
? {ihhuang,czyang}@syslab.cse.yzu.edu.tw <czyang%7D at syslab.cse.yzu.edu.tw>
? {s922344,s922351}@mail.yzu.edu.tw <s922351%7D at mail.yzu.edu.tw>
{ihhuang,czyang}@syslab.cse.yzu.edu.tw <czyang%7D at syslab.cse.yzu.edu.tw>



-- 
Jeremy Nickurak -= Email/XMPP: jeremy at nickurak.ca =-

From philipp.marek at linbit.com  Wed Jun  9 18:18:53 2010
From: philipp.marek at linbit.com (Philipp Marek)
Date: Wed, 9 Jun 2010 10:18:53 +0200
Subject: LPK integration - summary and ideas
Message-ID: <201006091018.53170.philipp.marek@linbit.com>

Hello everybody,

I'd like to have LPK (or something like that - getting public keys from 
LDAP) integrated into mainline OpenSSH.


*** First of all, a summary.

The project page at

	http://code.google.com/p/openssh-lpk/

mentions that a few distributions include LPK per default; but reading the 
various threads at

	Support for merging LPK and hpn-ssh into mainline openssh?
	http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2

and

	Support for merging LPK into mainline openssh?
	http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2

I get the impression that the most important argument is this one, citing 
Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2):
> Because the API presented by the LDAP libraries that I have looked at is
> quite ugly, because different platforms have different favourite LDAP
> APIs, because we don't want to build in support for every crazy variant
> schema that people will inevitably come up with.

Regarding the other way, ie. using another process, (from the same mail)
> On Wed, 9 Sep 2009, Howard Chu wrote:
> > Hmm. Pushing this out to a separate process requires inventing yet
> > another IPC protocol, and adds one more moving piece that can break.
> > How does this approach avoid complexity?
> 
> It avoids complexity in the critical part - the sshd daemon. It is more
> orthogonal too - if someone wants to store keys in xyzdb then they can
> make a subprocess to do that too.

there's another catch:
> > One thing that would be good is having some sort of signing mechnanism
> > on the Agent. As I see you check to make sure the ownership of the
> > file is ok.
> > 
> > How about another approach is to sign the Agent with the servers
> > private key (if that's possible??).
> Maybe may be included SHA hash of agent program in the config file
> and it may be checked before running the agent. But it is necessary?
> and who will check all the shared libraies used?


*** Brainstorming

So, given that arguments, I'd like to offer a few ideas that might help.

1) How about loading some shared library (libraries) for retrieving
   public keys? The library would provide interfaces like an 
   init(), uninit(), and lookup().
   Lookup would get the username and public key, and return a string
   describing the login options ("environment=...") or NULL for no
   public key found.
   Alternatively it could provide a function for returning a list
   of public keys, but I think doing a single lookup would be better.

2) If a separate process is the better way, how about skipping the
   signature idea and instead provide the same level of securiy as
   sshd itself?
   Just open two pipes (STDIN, STDOUT) to an external program started
   on sshd startup, use them for communication, and if the handles ever
   get closed just log an error and don't use them anymore.
   So if the external program gets changed on disk it wouldn't matter
   (or at least, only as far as changing /usr/sbin/sshd would, too).

3) The other idea I heard (but more of a joke, I think) was to use
   FUSE to provide the public keys from LDAP.


I'd like all interested parties to participate in this thread, to get a 
discussion going, and get an approximate level of community interest.


Thank you for all answers.


Regards,

Phil

From dan at doxpara.com  Wed Jun  9 18:22:47 2010
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 9 Jun 2010 04:22:47 -0400
Subject: LPK integration - summary and ideas
In-Reply-To: <201006091018.53170.philipp.marek@linbit.com>
References: <201006091018.53170.philipp.marek@linbit.com>
Message-ID: <AANLkTilxiU83uBFNSwiRMRh8TsB4eT-ZNKahtq4Pky07@mail.gmail.com>

There's long history of using external commands as an extensibility point
(ProxyCommand for example) and, if there was going to be any way of linking
LDAP in, this would almost certainly be the best way.

On Wed, Jun 9, 2010 at 4:18 AM, Philipp Marek <philipp.marek at linbit.com>wrote:

> Hello everybody,
>
> I'd like to have LPK (or something like that - getting public keys from
> LDAP) integrated into mainline OpenSSH.
>
>
> *** First of all, a summary.
>
> The project page at
>
>        http://code.google.com/p/openssh-lpk/
>
> mentions that a few distributions include LPK per default; but reading the
> various threads at
>
>        Support for merging LPK and hpn-ssh into mainline openssh?
>        http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2
>
> and
>
>        Support for merging LPK into mainline openssh?
>        http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2
>
> I get the impression that the most important argument is this one, citing
> Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2
> ):
> > Because the API presented by the LDAP libraries that I have looked at is
> > quite ugly, because different platforms have different favourite LDAP
> > APIs, because we don't want to build in support for every crazy variant
> > schema that people will inevitably come up with.
>
> Regarding the other way, ie. using another process, (from the same mail)
> > On Wed, 9 Sep 2009, Howard Chu wrote:
> > > Hmm. Pushing this out to a separate process requires inventing yet
> > > another IPC protocol, and adds one more moving piece that can break.
> > > How does this approach avoid complexity?
> >
> > It avoids complexity in the critical part - the sshd daemon. It is more
> > orthogonal too - if someone wants to store keys in xyzdb then they can
> > make a subprocess to do that too.
>
> there's another catch:
> > > One thing that would be good is having some sort of signing mechnanism
> > > on the Agent. As I see you check to make sure the ownership of the
> > > file is ok.
> > >
> > > How about another approach is to sign the Agent with the servers
> > > private key (if that's possible??).
> > Maybe may be included SHA hash of agent program in the config file
> > and it may be checked before running the agent. But it is necessary?
> > and who will check all the shared libraies used?
>
>
> *** Brainstorming
>
> So, given that arguments, I'd like to offer a few ideas that might help.
>
> 1) How about loading some shared library (libraries) for retrieving
>   public keys? The library would provide interfaces like an
>   init(), uninit(), and lookup().
>   Lookup would get the username and public key, and return a string
>   describing the login options ("environment=...") or NULL for no
>   public key found.
>   Alternatively it could provide a function for returning a list
>   of public keys, but I think doing a single lookup would be better.
>
> 2) If a separate process is the better way, how about skipping the
>   signature idea and instead provide the same level of securiy as
>   sshd itself?
>   Just open two pipes (STDIN, STDOUT) to an external program started
>   on sshd startup, use them for communication, and if the handles ever
>   get closed just log an error and don't use them anymore.
>   So if the external program gets changed on disk it wouldn't matter
>   (or at least, only as far as changing /usr/sbin/sshd would, too).
>
> 3) The other idea I heard (but more of a joke, I think) was to use
>   FUSE to provide the public keys from LDAP.
>
>
> I'd like all interested parties to participate in this thread, to get a
> discussion going, and get an approximate level of community interest.
>
>
> Thank you for all answers.
>
>
> Regards,
>
> Phil
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From hyc at symas.com  Wed Jun  9 22:40:29 2010
From: hyc at symas.com (Howard Chu)
Date: Wed, 09 Jun 2010 05:40:29 -0700
Subject: LPK integration - summary and ideas
In-Reply-To: <201006091018.53170.philipp.marek@linbit.com>
References: <201006091018.53170.philipp.marek@linbit.com>
Message-ID: <4C0F8BBD.80501@symas.com>

Philipp Marek wrote:
> Hello everybody,
>
> I'd like to have LPK (or something like that - getting public keys from
> LDAP) integrated into mainline OpenSSH.
>
>
> *** First of all, a summary.
>
> The project page at
>
> 	http://code.google.com/p/openssh-lpk/
>
> mentions that a few distributions include LPK per default; but reading the
> various threads at
>
> 	Support for merging LPK and hpn-ssh into mainline openssh?
> 	http://marc.info/?l=openssh-unix-dev&m=123483016220368&w=2
>
> and
>
> 	Support for merging LPK into mainline openssh?
> 	http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2
>
> I get the impression that the most important argument is this one, citing
> Damien Miller (http://marc.info/?l=openssh-unix-dev&m=125252189630862&w=2):
>> Because the API presented by the LDAP libraries that I have looked at is
>> quite ugly, because different platforms have different favourite LDAP
>> APIs, because we don't want to build in support for every crazy variant
>> schema that people will inevitably come up with.

This argument doesn't hold much water any more; the Mozilla LDAP library has 
been abandoned. Novell has been shipping OpenLDAP's library for over a decade. 
The Mozilla project supports OpenLDAP's library. Sun was in the process of 
migrating off the Mozilla library and onto OpenLDAP (dunno how that has 
progressed since the Oracle acquisition). Even the FedoraDS/389DS guys are 
supporting OpenLDAP's library now. The API may still be ugly, but there's only 
one now, not several.

> Regarding the other way, ie. using another process, (from the same mail)
>> On Wed, 9 Sep 2009, Howard Chu wrote:
>>> Hmm. Pushing this out to a separate process requires inventing yet
>>> another IPC protocol, and adds one more moving piece that can break.
>>> How does this approach avoid complexity?
>>
>> It avoids complexity in the critical part - the sshd daemon. It is more
>> orthogonal too - if someone wants to store keys in xyzdb then they can
>> make a subprocess to do that too.
>
> there's another catch:
>>> One thing that would be good is having some sort of signing mechnanism
>>> on the Agent. As I see you check to make sure the ownership of the
>>> file is ok.
>>>
>>> How about another approach is to sign the Agent with the servers
>>> private key (if that's possible??).
>> Maybe may be included SHA hash of agent program in the config file
>> and it may be checked before running the agent. But it is necessary?
>> and who will check all the shared libraies used?
>
>
> *** Brainstorming
>
> So, given that arguments, I'd like to offer a few ideas that might help.
>
> 1) How about loading some shared library (libraries) for retrieving
>     public keys? The library would provide interfaces like an
>     init(), uninit(), and lookup().
>     Lookup would get the username and public key, and return a string
>     describing the login options ("environment=...") or NULL for no
>     public key found.
>     Alternatively it could provide a function for returning a list
>     of public keys, but I think doing a single lookup would be better.
>
> 2) If a separate process is the better way, how about skipping the
>     signature idea and instead provide the same level of securiy as
>     sshd itself?
>     Just open two pipes (STDIN, STDOUT) to an external program started
>     on sshd startup, use them for communication, and if the handles ever
>     get closed just log an error and don't use them anymore.
>     So if the external program gets changed on disk it wouldn't matter
>     (or at least, only as far as changing /usr/sbin/sshd would, too).

On modern POSIX systems you can now reliably determine the uid/gid of the peer 
of a Unix Domain socket, so there's really no need to invent fancier solutions 
here.

> 3) The other idea I heard (but more of a joke, I think) was to use
>     FUSE to provide the public keys from LDAP.
>
>
> I'd like all interested parties to participate in this thread, to get a
> discussion going, and get an approximate level of community interest.
>
>
> Thank you for all answers.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From philipp.marek at linbit.com  Wed Jun  9 22:57:49 2010
From: philipp.marek at linbit.com (Philipp Marek)
Date: Wed, 9 Jun 2010 14:57:49 +0200
Subject: LPK integration - summary and ideas
In-Reply-To: <4C0F8BBD.80501@symas.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<4C0F8BBD.80501@symas.com>
Message-ID: <201006091457.50131.philipp.marek@linbit.com>

Hello Howard,

Am Mittwoch, 9. Juni 2010, 14:40:29 schrieb Howard Chu:
> > 2) If a separate process is the better way, how about skipping the
> >     signature idea and instead provide the same level of securiy as
> >     sshd itself?
> >     Just open two pipes (STDIN, STDOUT) to an external program started
> >     on sshd startup, use them for communication, and if the handles
> >     ever get closed just log an error and don't use them anymore.
> >     So if the external program gets changed on disk it wouldn't matter
> >     (or at least, only as far as changing /usr/sbin/sshd would, too).
> 
> On modern POSIX systems you can now reliably determine the uid/gid of the
> peer of a Unix Domain socket, so there's really no need to invent
> fancier solutions here.
I should have been more clear here.

What this should help against is (I think) that the external process gets 
hijacked to provide attacker-supplied authorization information.

The original mail wanted to check some kind of signature; to make that 
easier I proposed to just start the process once, with sshd, so that a 
simple file rename isn't sufficient to gain access.


Or maybe I just don't understand you - why do you want to check the UID/GID 
of the auxillary process?


Regards,

Phil

From Naitik.Dani at netapp.com  Thu Jun 10 01:14:41 2010
From: Naitik.Dani at netapp.com (Dani, Naitik)
Date: Wed, 9 Jun 2010 11:14:41 -0400
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <20100607232252.GG19561@linux55.nas.nasa.gov>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
Message-ID: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>

I did the following steps to create a certficate, but it does not work:


  1) Client: ssh-keygen -f ca_key
  2) Client: ssh-keygen -f user_key
  3) Client: ssh-keygen -s ca_key -I 2 -n USER user_key.pub
  4) Server: cp ca_key.pub ~/.ssh/authorized_keys
  5) I tagged the entry in authorized_keys as follows with
cert-authority, is this correct:
cert-authority ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDscbUTgHMo+bryVqKHbItgd1THR4fVvjRdrDd3ZoEo
oPA8iz/AR9umzn19rAeuRIKRYUnRsslaAVnAji6Hl1To51xoKQuV63cykCM+smxqsEIO8ThG
eF/oH/HfAnpdDfZ7Lkh2n6n4ixwEygjQ0M9gnAZkyKBoq08rGp3vCZUFRCOTH3Xpdsy8kIqF
xNdYyGNyLr3RpneSGJ9V99n4UmeUkm0ofVI0BaL0aCe4t1WTHQoeAXJ USER at server1  
  5) Client: ssh USER at server --> it failed

What should I do with user_key-cert.pub file which gets created in step
3? Where should I copy this file?
Do I need to copy user_key/user_key.pub in ~/.ssh/ directory as
id_rsa/id_rsa.pub on the server side?

Thanks in advance.

Naitik Dani
MTS
GX Infrastructure HQ

NetApp
724-741-5153 Direct
Naitik.Dani at netapp.com
www.netapp.com



 

> -----Original Message-----
> From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
> Sent: Monday, June 07, 2010 19:23
> To: Dani, Naitik
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: X509 based certificate authentication in OpenSSH
> 
> On Mon, Jun 07, 2010 at 17:04:09 -0500, Dani, Naitik wrote:
> > Hello,
> > 
> > I would like to know whether OpenSSH supports x509 certificate based
> > authentication.
> 
> No, although Roumen Petrov maintains a patch that adds such support.
> 
> > It looks like OpenSSH has dependency on OpenSSL so does 
> this mean that
> > OpeSSH also supports x509 certificate based authentication.
> 
> No, OpenSSH just uses the low-level cryptographic algorithms from
> OpenSSL.
> 
> > 
> > If it does support, can you please point me to the necessary
> > documentation. 
> > 
> 
> The developers have maintained a stance that the complexity of X.509
> certificates introduces an unacceptable attack surface for sshd.
> Instead, they have recently implemented an alternative certificate
> format which is much simpler to parse and thus introduces 
> less risk. See
> the various man pages in OpenSSH 5.5 for more information.
> 
> -- 
> Iain Morgan
> 

From dkg at fifthhorseman.net  Thu Jun 10 01:14:43 2010
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Jun 2010 11:14:43 -0400
Subject: LPK integration - summary and ideas
In-Reply-To: <AANLkTilxiU83uBFNSwiRMRh8TsB4eT-ZNKahtq4Pky07@mail.gmail.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<AANLkTilxiU83uBFNSwiRMRh8TsB4eT-ZNKahtq4Pky07@mail.gmail.com>
Message-ID: <4C0FAFE3.9090600@fifthhorseman.net>

On 06/09/2010 04:22 AM, Dan Kaminsky wrote:
> There's long history of using external commands as an extensibility point
> (ProxyCommand for example) and, if there was going to be any way of linking
> LDAP in, this would almost certainly be the best way.

I agree with Dan here.  I'd rather see a general, out-of-process,
extensible framework put in place than see LPK integrated directly.

For the client side, something like KnownHostsCommand (by analogy with
KnownHostsFile) would be good.  I've just opened a ticket describing a
simple outline for that enhancement:

 https://bugzilla.mindrot.org/show_bug.cgi?id=1777

For the server side, it's a bit tricker to define an
AuthorizedKeysCommand (and to ensure that a blocked
AuthorizedKeysCommand does not hang the rest of the daemon), but it
would be useful too.  I've opened a ticket describing that option as
well (but it's not as well fleshed-out):

 https://bugzilla.mindrot.org/show_bug.cgi?id=1778

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100609/3a72194a/attachment.bin>

From jchadima at redhat.com  Thu Jun 10 00:33:07 2010
From: jchadima at redhat.com (Jan Chadima)
Date: Wed, 9 Jun 2010 10:33:07 -0400 (EDT)
Subject: LPK integration - summary and ideas
In-Reply-To: <201006091018.53170.philipp.marek@linbit.com>
Message-ID: <1827951812.599041276093987757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Philipp Marek" <philipp.marek at linbit.com> wrote:

> Hello everybody,
> 
> I'd like to have LPK (or something like that - getting public keys
> from 
> LDAP) integrated into mainline OpenSSH.
> 
> 
> *** First of all, a summary.
> 
> The project page at
> 
> 	http://code.google.com/p/openssh-lpk/
> 

There is an attempt of a successor at https://bugzilla.mindrot.org/show_bug.cgi?id=1668
It uses the same schema as tratitional lpk, the ldap-agent is run from sshd (once per authorization in this version).

-- 
JFCh <jchadima at redhat.com>

From imorgan at nas.nasa.gov  Thu Jun 10 03:36:25 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 9 Jun 2010 10:36:25 -0700
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
Message-ID: <20100609173625.GD30208@linux55.nas.nasa.gov>

Hi Naitik,

One thing I neglected to point out in my earlier off-list response to
you is that your use of the -n option may create a complication.
Specifically, using '-n USER' will restrict the certificate to only
being able to authenticate to a USEr account.

When sshd encounters a certificate that has a non-empty list of
principals (as specified by the -n option to ssh-keygen), it will
compare the username of the account being logged into against this list.
If the name of the remote account is not in the list of principals, the
certificate will be rejected.

Other than that caveat, what you have described looks correct.

You don't need to do anything with the -cert.pub file that was created.
Simply keep it in the same directory as the associated private key. In
particular, there is no need to copy it to remote hosts. You would only
need to copy the public key, user_key.pub, to servers that do not
support the certificate format, i.e. any older than OpenSSH 5.4 or any
server using something other than OpenSSH. And you should _never_ copy
the private key to a remote host.

Simply keep the private key, public key and certificate (user_key,
user_key.pub, and user_key-cert.pub respectively) in Your ~/.ssh
directory on the client system. Note that since you chose to use a
non-default name for the key (and thus the cert) you will need to
explicitly tell ssh to load the key/cert either with the -i command-line
option or the IdentityFile option in ~/.ssh/config.

On Wed, Jun 09, 2010 at 10:14:41 -0500, Dani, Naitik wrote:
> I did the following steps to create a certficate, but it does not work:
> 
> 
>   1) Client: ssh-keygen -f ca_key
>   2) Client: ssh-keygen -f user_key
>   3) Client: ssh-keygen -s ca_key -I 2 -n USER user_key.pub
>   4) Server: cp ca_key.pub ~/.ssh/authorized_keys
>   5) I tagged the entry in authorized_keys as follows with
> cert-authority, is this correct:
> cert-authority ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDscbUTgHMo+bryVqKHbItgd1THR4fVvjRdrDd3ZoEo
> oPA8iz/AR9umzn19rAeuRIKRYUnRsslaAVnAji6Hl1To51xoKQuV63cykCM+smxqsEIO8ThG
> eF/oH/HfAnpdDfZ7Lkh2n6n4ixwEygjQ0M9gnAZkyKBoq08rGp3vCZUFRCOTH3Xpdsy8kIqF
> xNdYyGNyLr3RpneSGJ9V99n4UmeUkm0ofVI0BaL0aCe4t1WTHQoeAXJ USER at server1  
>   5) Client: ssh USER at server --> it failed
> 
> What should I do with user_key-cert.pub file which gets created in step
> 3? Where should I copy this file?
> Do I need to copy user_key/user_key.pub in ~/.ssh/ directory as
> id_rsa/id_rsa.pub on the server side?
> 
> Thanks in advance.
> 
> Naitik Dani
> MTS
> GX Infrastructure HQ
> 
> NetApp
> 724-741-5153 Direct
> Naitik.Dani at netapp.com
> www.netapp.com
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
> > Sent: Monday, June 07, 2010 19:23
> > To: Dani, Naitik
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: Re: X509 based certificate authentication in OpenSSH
> > 
> > On Mon, Jun 07, 2010 at 17:04:09 -0500, Dani, Naitik wrote:
> > > Hello,
> > > 
> > > I would like to know whether OpenSSH supports x509 certificate based
> > > authentication.
> > 
> > No, although Roumen Petrov maintains a patch that adds such support.
> > 
> > > It looks like OpenSSH has dependency on OpenSSL so does 
> > this mean that
> > > OpeSSH also supports x509 certificate based authentication.
> > 
> > No, OpenSSH just uses the low-level cryptographic algorithms from
> > OpenSSL.
> > 
> > > 
> > > If it does support, can you please point me to the necessary
> > > documentation. 
> > > 
> > 
> > The developers have maintained a stance that the complexity of X.509
> > certificates introduces an unacceptable attack surface for sshd.
> > Instead, they have recently implemented an alternative certificate
> > format which is much simpler to parse and thus introduces 
> > less risk. See
> > the various man pages in OpenSSH 5.5 for more information.
> > 
> > -- 
> > Iain Morgan
> > 

-- 
Iain Morgan

From bob at proulx.com  Thu Jun 10 03:51:51 2010
From: bob at proulx.com (Bob Proulx)
Date: Wed, 9 Jun 2010 11:51:51 -0600
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
References: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
Message-ID: <20100609175151.GB2626@dementia.proulx.com>

Jeremy Nickurak wrote:
> I just stumbled across this thread on openssh-dev...
> 
> Is there anywhere to track progress on this issue? It'd be a fantastic
> feature that would fix all sorts of problems I deal with regularly.

I use the 'autossh' wrapper to really good effect.  It works
awesomely!  For my use autossh handles the task so well that I
personally don't have any need for anything beyond it.

  http://www.harding.motd.ca/autossh/

Bob

From jeremy at nickurak.ca  Thu Jun 10 03:54:13 2010
From: jeremy at nickurak.ca (Jeremy Nickurak)
Date: Wed, 9 Jun 2010 11:54:13 -0600
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <20100609175151.GB2626@dementia.proulx.com>
References: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
	<20100609175151.GB2626@dementia.proulx.com>
Message-ID: <AANLkTinZND8wfIcndZV_8VXj1O39BlHg88b3RpEprYz5@mail.gmail.com>

On Wed, Jun 9, 2010 at 11:51, Bob Proulx <bob at proulx.com> wrote:
>
> I use the 'autossh' wrapper to really good effect.  It works
> awesomely!  For my use autossh handles the task so well that I
> personally don't have any need for anything beyond it.
>
>  http://www.harding.motd.ca/autossh/
>

Does this correctly and transparently resume forwarded streams when your
client's IP address changes?

-- 
Jeremy Nickurak -= Email/XMPP: jeremy at nickurak.ca =-

From dan at doxpara.com  Thu Jun 10 01:33:26 2010
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 9 Jun 2010 11:33:26 -0400
Subject: LPK integration - summary and ideas
In-Reply-To: <201006091457.50131.philipp.marek@linbit.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<4C0F8BBD.80501@symas.com>
	<201006091457.50131.philipp.marek@linbit.com>
Message-ID: <AANLkTimxR1XcV-8AnL-IuBzBYDVUgUuDJmK0TPjUXzcC@mail.gmail.com>

> What this should help against is (I think) that the external process gets
> hijacked to provide attacker-supplied authorization information.
>
> The original mail wanted to check some kind of signature; to make that
> easier I proposed to just start the process once, with sshd, so that a
> simple file rename isn't sufficient to gain access.
>

This is a false security boundary.  At the point where file renames work,
there is little that can be done to defend against attack.  (False security
boundaries are _incredibly_ dangerous, as they consume all oxygen as they're
repeatedly patched up.)

I could see some wisdom in requiring a full path to the ExternalAuthCommand
app, though, since we already have such a requirement for sshd itself.

--Dan

From bob at proulx.com  Thu Jun 10 04:20:44 2010
From: bob at proulx.com (Bob Proulx)
Date: Wed, 9 Jun 2010 12:20:44 -0600
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <AANLkTinZND8wfIcndZV_8VXj1O39BlHg88b3RpEprYz5@mail.gmail.com>
References: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
	<20100609175151.GB2626@dementia.proulx.com>
	<AANLkTinZND8wfIcndZV_8VXj1O39BlHg88b3RpEprYz5@mail.gmail.com>
Message-ID: <20100609182044.GB3935@dementia.proulx.com>

Jeremy Nickurak wrote:
> Bob Proulx wrote:
> > I use the 'autossh' wrapper to really good effect.  It works
> > awesomely!  For my use autossh handles the task so well that I
> > personally don't have any need for anything beyond it.
> >
> >  http://www.harding.motd.ca/autossh/
> 
> Does this correctly and transparently resume forwarded streams when your
> client's IP address changes?

I use it for exactly that purpose.  It was originally recommended to
me from someone who uses it with 'screen' for a resumable terminal
session.  I have tried it for that and it works well for that purpose
but that wasn't my need.

I use it to control ssh to set up port forwards to other machines in
dynamic IP address space.  It is a more lightweight solution than a
full VPN for attaching a dynamic IP client to a static IP server so as
to be able to port forward to it.  Specifically I port forward 22, 25,
and 80 through from the static IP to the dynamic IP.  Then I can 1)
always log into the dynamic IP machine 2) forward email to the dynamic
IP machine 3) locate a web server on the dynamic IP machine and proxy
content (in this case personal photo albums) through it.

> Does this correctly and transparently resume forwarded streams when your
> client's IP address changes?

Having said what I said I do note that you say "transparently resume
forwarded streams" and will respond with ... no.  For the protocols I
use it for that isn't needed.  And no it doesn't.  It will spawn a new
ssh process which will open a new port forward connection.  In use
with screen it will resume the terminal session and you won't know the
difference.  Using it with vnc or nxclient the previous session will
be resumed and you won't know the difference.  But I realize that it
isn't the same as transparently resuming a previously opened TCP
connection already with data flow in progress.  But I think few
applications really truly need that level of resume.  If I needed that
I would go with a /dev/tun solution.  Personally for that purpose I
recommend OpenVPN.  That works well but is a heavier and relatively
more complicated solution.

Bob

From jeremy at nickurak.ca  Thu Jun 10 04:25:30 2010
From: jeremy at nickurak.ca (Jeremy Nickurak)
Date: Wed, 9 Jun 2010 12:25:30 -0600
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <20100609182044.GB3935@dementia.proulx.com>
References: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
	<20100609175151.GB2626@dementia.proulx.com>
	<AANLkTinZND8wfIcndZV_8VXj1O39BlHg88b3RpEprYz5@mail.gmail.com>
	<20100609182044.GB3935@dementia.proulx.com>
Message-ID: <AANLkTinG2eKLHinNffoAEQmI9GRHYA0r6kL22QmWHuaY@mail.gmail.com>

On Wed, Jun 9, 2010 at 12:20, Bob Proulx <bob at proulx.com> wrote:

> Having said what I said I do note that you say "transparently resume
> forwarded streams" and will respond with ... no.  For the protocols I
> use it for that isn't needed.  And no it doesn't.  It will spawn a new
> ssh process which will open a new port forward connection.  In use
> with screen it will resume the terminal session and you won't know the
> difference.  Using it with vnc or nxclient the previous session will
> be resumed and you won't know the difference.  But I realize that it
> isn't the same as transparently resuming a previously opened TCP
> connection already with data flow in progress.  But I think few
> applications really truly need that level of resume.  If I needed that
> I would go with a /dev/tun solution.  Personally for that purpose I
> recommend OpenVPN.  That works well but is a heavier and relatively
> more complicated solution.


That's consistent with my understanding :) I'm not interested in screen/vnc
sessions, i'm interested in long-running arbitrary tcp connections... and it
sounds like there's at least a couple implementations that make that work in
a very light-weight way.


-- 
Jeremy Nickurak -= Email/XMPP: jeremy at nickurak.ca =-

From Naitik.Dani at netapp.com  Thu Jun 10 06:09:49 2010
From: Naitik.Dani at netapp.com (Dani, Naitik)
Date: Wed, 9 Jun 2010 16:09:49 -0400
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <20100609173625.GD30208@linux55.nas.nasa.gov>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609173625.GD30208@linux55.nas.nasa.gov>
Message-ID: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D707C@RTPMVEXC1-PRD.hq.netapp.com>

> particular, there is no need to copy it to remote hosts. You 
> would only
> need to copy the public key, user_key.pub, to servers that do not
> support the certificate format, i.e. any older than OpenSSH 5.4 or any
> server using something other than OpenSSH. And you should _never_ copy
> the private key to a remote host.

Does this mean that, if my servers do support certificate format, i.e.
newer than OpenSSH 5.4, then I need to copy user_key-cert.pub into
~/.ssh/authorized_keys instead of user_key.pub?

I tried that, and the connection failed. Is this the expected behavior
or am I missing something?

Thanks

Naitik Dani
MTS
GX Infrastructure HQ

NetApp
724-741-5153 Direct
Naitik.Dani at netapp.com
www.netapp.com



 

> -----Original Message-----
> From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
> Sent: Wednesday, June 09, 2010 13:36
> To: Dani, Naitik
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: X509 based certificate authentication in OpenSSH
> 
> Hi Naitik,
> 
> One thing I neglected to point out in my earlier off-list response to
> you is that your use of the -n option may create a complication.
> Specifically, using '-n USER' will restrict the certificate to only
> being able to authenticate to a USEr account.
> 
> When sshd encounters a certificate that has a non-empty list of
> principals (as specified by the -n option to ssh-keygen), it will
> compare the username of the account being logged into against 
> this list.
> If the name of the remote account is not in the list of 
> principals, the
> certificate will be rejected.
> 
> Other than that caveat, what you have described looks correct.
> 
> You don't need to do anything with the -cert.pub file that 
> was created.
> Simply keep it in the same directory as the associated private key. In
> particular, there is no need to copy it to remote hosts. You 
> would only
> need to copy the public key, user_key.pub, to servers that do not
> support the certificate format, i.e. any older than OpenSSH 5.4 or any
> server using something other than OpenSSH. And you should _never_ copy
> the private key to a remote host.
> 
> Simply keep the private key, public key and certificate (user_key,
> user_key.pub, and user_key-cert.pub respectively) in Your ~/.ssh
> directory on the client system. Note that since you chose to use a
> non-default name for the key (and thus the cert) you will need to
> explicitly tell ssh to load the key/cert either with the -i 
> command-line
> option or the IdentityFile option in ~/.ssh/config.
> 
> On Wed, Jun 09, 2010 at 10:14:41 -0500, Dani, Naitik wrote:
> > I did the following steps to create a certficate, but it 
> does not work:
> > 
> > 
> >   1) Client: ssh-keygen -f ca_key
> >   2) Client: ssh-keygen -f user_key
> >   3) Client: ssh-keygen -s ca_key -I 2 -n USER user_key.pub
> >   4) Server: cp ca_key.pub ~/.ssh/authorized_keys
> >   5) I tagged the entry in authorized_keys as follows with
> > cert-authority, is this correct:
> > cert-authority ssh-rsa
> > 
> AAAAB3NzaC1yc2EAAAADAQABAAABAQDscbUTgHMo+bryVqKHbItgd1THR4fVvj
> RdrDd3ZoEo
> > 
> oPA8iz/AR9umzn19rAeuRIKRYUnRsslaAVnAji6Hl1To51xoKQuV63cykCM+sm
> xqsEIO8ThG
> > 
> eF/oH/HfAnpdDfZ7Lkh2n6n4ixwEygjQ0M9gnAZkyKBoq08rGp3vCZUFRCOTH3
> Xpdsy8kIqF
> > xNdYyGNyLr3RpneSGJ9V99n4UmeUkm0ofVI0BaL0aCe4t1WTHQoeAXJ 
> USER at server1  
> >   5) Client: ssh USER at server --> it failed
> > 
> > What should I do with user_key-cert.pub file which gets 
> created in step
> > 3? Where should I copy this file?
> > Do I need to copy user_key/user_key.pub in ~/.ssh/ directory as
> > id_rsa/id_rsa.pub on the server side?
> > 
> > Thanks in advance.
> > 
> > Naitik Dani
> > MTS
> > GX Infrastructure HQ
> > 
> > NetApp
> > 724-741-5153 Direct
> > Naitik.Dani at netapp.com
> > www.netapp.com
> > 
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
> > > Sent: Monday, June 07, 2010 19:23
> > > To: Dani, Naitik
> > > Cc: openssh-unix-dev at mindrot.org
> > > Subject: Re: X509 based certificate authentication in OpenSSH
> > > 
> > > On Mon, Jun 07, 2010 at 17:04:09 -0500, Dani, Naitik wrote:
> > > > Hello,
> > > > 
> > > > I would like to know whether OpenSSH supports x509 
> certificate based
> > > > authentication.
> > > 
> > > No, although Roumen Petrov maintains a patch that adds 
> such support.
> > > 
> > > > It looks like OpenSSH has dependency on OpenSSL so does 
> > > this mean that
> > > > OpeSSH also supports x509 certificate based authentication.
> > > 
> > > No, OpenSSH just uses the low-level cryptographic algorithms from
> > > OpenSSL.
> > > 
> > > > 
> > > > If it does support, can you please point me to the necessary
> > > > documentation. 
> > > > 
> > > 
> > > The developers have maintained a stance that the 
> complexity of X.509
> > > certificates introduces an unacceptable attack surface for sshd.
> > > Instead, they have recently implemented an alternative certificate
> > > format which is much simpler to parse and thus introduces 
> > > less risk. See
> > > the various man pages in OpenSSH 5.5 for more information.
> > > 
> > > -- 
> > > Iain Morgan
> > > 
> 
> -- 
> Iain Morgan
> 

From daniel.espinosa at ge.com  Thu Jun 10 08:42:04 2010
From: daniel.espinosa at ge.com (Daniel)
Date: Wed, 9 Jun 2010 22:42:04 +0000 (UTC)
Subject: disable sftp log
Message-ID: <loom.20100610T003838-876@post.gmane.org>

Hi, 

I need to disable the messages of the sftp while connecting or fetching or
anything but the errors.

When I type sftp user at server > $logfile
all the messages are written inthe $logfile

but I need that only the errors be written there.

Now it shows:
connecting to "server"
fetching /path/file to /path2/file


how can I avoid this?

thanks in advance.
Dany



From imorgan at nas.nasa.gov  Thu Jun 10 09:05:26 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 9 Jun 2010 16:05:26 -0700
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <20100419192343.GA26131@zzlevo.net>
References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly>
	<20100419192343.GA26131@zzlevo.net>
Message-ID: <20100609230526.GI19561@linux55.nas.nasa.gov>

On Mon, Apr 19, 2010 at 14:23:43 -0500, Andreas Gunnarsson wrote:
> > On Sun, Apr 18, 2010 at 05:26:06PM -0500, Misha Koshelev wrote:
> > > I was wondering if it might at all be possible to have the following functionality in OpenSSH:
> > > (i) upon "timeout" of connection (say 2-5 seconds) disconnect
> > > (ii) keep trying to reconnect
> > > (iii) upon reconnection, resume session exactly where started
> 
> On Mon, Apr 19, 2010 at 01:08:36PM +0200, Markus Friedl wrote:
> > this is a work-in-progress, some parts are already commited to
> > the released versions. other parts need to be reviewed.
> > 
> > Andreas can provide details, I think -- and yes, I should 
> > look into reviewing the remaining patches.......
> 
> I've made the patch available here:
> 
>    http://www.zzlevo.net/ssh-roaming.diff
> 
> This is a diff against OpenBSD-current which adds "roaming" to allow an
> ssh session to be suspended (i.e. terminate the TCP session) and then
> resumed over a new TCP session. The client may resume from the same or a
> new IP address.
> 
> A solution which just sets up a new ssh session would tear down open
> port forwarded TCP sessions. This patch keeps the client and server
> processes running, and applications that use port forwards will not
> notice that the ssh session has been suspended and resumed.
> 
> The session is not resumed automatically (the user has to press return)
> but that could be a possible enhancement once this is committed. The
> patch is based on code written by Martin Forss?n and donated by my
> previous employer, AppGate. I haven't made a version for portable
> OpenSSH but anyone who wants to will probably be able to do that with
> minimal effort.
> 
> As Markus said, this hasn't been fully audited yet. It does touch the
> preauth and privsep parts of the code so use on your own risk. :)
> 
>    Andreas

Hello Andreas,

The recent discussion on this thread reminded me that I had intended to
take a look at your patch. ;-)

At this point, I've only glanced at the patch, but it looks interesting
thus far. A scenario that I am particularly interested in is resumption
of long file transfers after network hiccups. (By 'long' I mean on the
order of 100GB to 1TB.) In such a scenario, hitting return to resume the
ssh session would not be effective. 

One solution would be to add the ability for ssh to automatically resume
the session. An alternative would be to add a 'resume' command to ssh's
-O option. Of course, this assumes that a ContolPath has been configured
for the client. This would also be useful for backgrounded
port-forwarding or multiplex master sessions.

Perhaps the -O support is already there, but I did not see it during my
cursory skim of the man page updates in the patch.

Regards,

-- 
Iain Morgan

From imorgan at nas.nasa.gov  Thu Jun 10 09:40:08 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 9 Jun 2010 16:40:08 -0700
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D707C@RTPMVEXC1-PRD.hq.netapp.com>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609173625.GD30208@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D707C@RTPMVEXC1-PRD.hq.netapp.com>
Message-ID: <20100609234008.GF30208@linux55.nas.nasa.gov>

On Wed, Jun 09, 2010 at 15:09:49 -0500, Dani, Naitik wrote:
> > particular, there is no need to copy it to remote hosts. You 
> > would only
> > need to copy the public key, user_key.pub, to servers that do not
> > support the certificate format, i.e. any older than OpenSSH 5.4 or any
> > server using something other than OpenSSH. And you should _never_ copy
> > the private key to a remote host.
> 
> Does this mean that, if my servers do support certificate format, i.e.
> newer than OpenSSH 5.4, then I need to copy user_key-cert.pub into
> ~/.ssh/authorized_keys instead of user_key.pub?

No, you _never_ need to add your *-cert.pub file to the
~/.ssh/authorized_keys file. You _only_ need to add the ca_key.pub file
with the cert-authority tag. That allows the server to detemine that the
certificate (which the client offers during authentication) is signed by
a trusted CA.

> 
> I tried that, and the connection failed. Is this the expected behavior
> or am I missing something?
> 
> Thanks
> 

Offhand, I'm not sure what the expected behaviour would be if you added
user_key-cert.pub to your authorized_keys file.  However, it would not
be of any benefit.

You may want to try using -v with ssh to see what actually is happening.
I suspect that either ssh is not actually using the certificate or that
you have a list of principals specified which does not match the account
you are trying to authenticate to.

You might also want to do 'ssh-keygen -Lf user_key-cert.pub' to verify
the parameters that are set for the certificate.

If those steps don't shed any light and you have sufficient access to
the server, you could check the system logs for further info regarding
the authentication attempt. For best results, you may need to set the
LogLevel on the server to 'verbose.'

-- 
Iain Morgan

From djm at mindrot.org  Thu Jun 10 13:36:09 2010
From: djm at mindrot.org (Damien Miller)
Date: Thu, 10 Jun 2010 13:36:09 +1000 (EST)
Subject: LPK integration - summary and ideas
In-Reply-To: <AANLkTilxiU83uBFNSwiRMRh8TsB4eT-ZNKahtq4Pky07@mail.gmail.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<AANLkTilxiU83uBFNSwiRMRh8TsB4eT-ZNKahtq4Pky07@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1006101335370.12496@fuyu.mindrot.org>

On Wed, 9 Jun 2010, Dan Kaminsky wrote:

> There's long history of using external commands as an extensibility point
> (ProxyCommand for example) and, if there was going to be any way of linking
> LDAP in, this would almost certainly be the best way.

Yes, there is a patch in bugzilla that does exactly that. Unfortunately,
I haven't had time to review it properly yet.

-d

From philipp.marek at linbit.com  Thu Jun 10 16:20:52 2010
From: philipp.marek at linbit.com (Philipp Marek)
Date: Thu, 10 Jun 2010 08:20:52 +0200
Subject: LPK integration - summary and ideas
In-Reply-To: <AANLkTimxR1XcV-8AnL-IuBzBYDVUgUuDJmK0TPjUXzcC@mail.gmail.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<201006091457.50131.philipp.marek@linbit.com>
	<AANLkTimxR1XcV-8AnL-IuBzBYDVUgUuDJmK0TPjUXzcC@mail.gmail.com>
Message-ID: <201006100820.52795.philipp.marek@linbit.com>

Hello Dan,

Am Mittwoch, 9. Juni 2010, 17:33:26 schrieb Dan Kaminsky:
> > What this should help against is (I think) that the external process
> > gets hijacked to provide attacker-supplied authorization information.
> > 
> > The original mail wanted to check some kind of signature; to make that
> > easier I proposed to just start the process once, with sshd, so that a
> > simple file rename isn't sufficient to gain access.
> This is a false security boundary.  At the point where file renames work,
> there is little that can be done to defend against attack.  
Well, that was just a guess on my side.

As I wrote, the mail at
	http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2
had a few lines discussion about (hash/signature) verification of the 
AuthorizedKeysCommand.

But as you'd have to check every library that might be loaded (including 
libnss*), even checking for LD_LIBRARY_PATH and so on, this might not be 
realistic.

So I proposed to only start the program once - that should provide 
sufficient security, I think, because /usr/sbin/sshd could be attacked the 
same way.


> I could see some wisdom in requiring a full path to the
> ExternalAuthCommand app, though, since we already have such a
> requirement for sshd itself.
Ok, fine.


Regards,

Phil

From jchadima at redhat.com  Thu Jun 10 17:25:11 2010
From: jchadima at redhat.com (Jan Chadima)
Date: Thu, 10 Jun 2010 03:25:11 -0400 (EDT)
Subject: LPK integration - summary and ideas
In-Reply-To: <1811723945.664151276154588398.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <1773617190.664371276154711881.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Damien Miller" <djm at mindrot.org> wrote:

> On Wed, 9 Jun 2010, Dan Kaminsky wrote:
> 
> > There's long history of using external commands as an extensibility
> point
> > (ProxyCommand for example) and, if there was going to be any way of
> linking
> > LDAP in, this would almost certainly be the best way.
> 
> Yes, there is a patch in bugzilla that does exactly that.
> Unfortunately,
> I haven't had time to review it properly yet.
> 
Damien, 
please review at least the sshd part of it. The sshd part is quite small
and pushing it into mainstream makes possibility of further improvements. To maintain the patch across the changes of openssh sources fatigues me.
Thx  


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

-- 
JFCh <jchadima at redhat.com>

From hyc at symas.com  Thu Jun 10 17:42:33 2010
From: hyc at symas.com (Howard Chu)
Date: Thu, 10 Jun 2010 00:42:33 -0700
Subject: LPK integration - summary and ideas
In-Reply-To: <201006100820.52795.philipp.marek@linbit.com>
References: <201006091018.53170.philipp.marek@linbit.com>
	<201006091457.50131.philipp.marek@linbit.com>
	<AANLkTimxR1XcV-8AnL-IuBzBYDVUgUuDJmK0TPjUXzcC@mail.gmail.com>
	<201006100820.52795.philipp.marek@linbit.com>
Message-ID: <4C109769.6000603@symas.com>

Philipp Marek wrote:
> Hello Dan,
>
> Am Mittwoch, 9. Juni 2010, 17:33:26 schrieb Dan Kaminsky:
>>> What this should help against is (I think) that the external process
>>> gets hijacked to provide attacker-supplied authorization information.
>>>
>>> The original mail wanted to check some kind of signature; to make that
>>> easier I proposed to just start the process once, with sshd, so that a
>>> simple file rename isn't sufficient to gain access.
>> This is a false security boundary.  At the point where file renames work,
>> there is little that can be done to defend against attack.

That was my point re: checking uid of the peer process being sufficient. If an 
attacker is already able to subvert files on the filesystem or assume the 
identity of a privileged server process, then all bets are off. You could go 
to the trouble of inventing a crypto handshake for IPC but it's wasted effort 
- either the machine's security is intact, and it's superfluous, or the 
machine has been compromised, and none of your key data is trustworthy.

When the system integrity really counts you'll have binaries and certificates 
mounted on a physically write-protected filesystem...

> Well, that was just a guess on my side.
>
> As I wrote, the mail at
> 	http://marc.info/?l=openssh-unix-dev&m=125655418812760&w=2
> had a few lines discussion about (hash/signature) verification of the
> AuthorizedKeysCommand.
>
> But as you'd have to check every library that might be loaded (including
> libnss*), even checking for LD_LIBRARY_PATH and so on, this might not be
> realistic.
>
> So I proposed to only start the program once - that should provide
> sufficient security, I think, because /usr/sbin/sshd could be attacked the
> same way.
>
>
>> I could see some wisdom in requiring a full path to the
>> ExternalAuthCommand app, though, since we already have such a
>> requirement for sshd itself.
> Ok, fine.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From jchadima at redhat.com  Thu Jun 10 17:52:03 2010
From: jchadima at redhat.com (Jan Chadima)
Date: Thu, 10 Jun 2010 03:52:03 -0400 (EDT)
Subject: LPK integration - summary and ideas
In-Reply-To: <1827951812.599041276093987757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <425468454.665621276156323210.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Jan Chadima" <jchadima at redhat.com> wrote:

> https://bugzilla.mindrot.org/show_bug.cgi?id=1668
sorry, bad bz#
correct is
https://bugzilla.mindrot.org/show_bug.cgi?id=1663

-- 
JFCh <jchadima at redhat.com>

From jchadima at redhat.com  Fri Jun 11 00:03:42 2010
From: jchadima at redhat.com (Jan Chadima)
Date: Thu, 10 Jun 2010 10:03:42 -0400 (EDT)
Subject: LPK integration - summary and ideas
In-Reply-To: <4C0FAFE3.9090600@fifthhorseman.net>
Message-ID: <195922799.689511276178622300.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>


----- "Daniel Kahn Gillmor" <dkg at fifthhorseman.net> wrote:

> On 06/09/2010 04:22 AM, Dan Kaminsky wrote:
> > There's long history of using external commands as an extensibility
> point
> > (ProxyCommand for example) and, if there was going to be any way of
> linking
> > LDAP in, this would almost certainly be the best way.
> 
> I agree with Dan here.  I'd rather see a general, out-of-process,
> extensible framework put in place than see LPK integrated directly.
> 
> For the client side, something like KnownHostsCommand (by analogy
> with
> KnownHostsFile) would be good.  I've just opened a ticket describing
> a
> simple outline for that enhancement:
> 
>  https://bugzilla.mindrot.org/show_bug.cgi?id=1777
> 
> For the server side, it's a bit tricker to define an
> AuthorizedKeysCommand (and to ensure that a blocked
> AuthorizedKeysCommand does not hang the rest of the daemon), but it
> would be useful too.  I've opened a ticket describing that option as
> well (but it's not as well fleshed-out):
> 
>  https://bugzilla.mindrot.org/show_bug.cgi?id=1778
> 
> 	--dkg
> 

please look at 
https://bugzilla.mindrot.org/show_bug.cgi?id=1663
there is a patch solving the above requests
+ some ldap backend also

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

-- 
JFCh <jchadima at redhat.com>

From Naitik.Dani at netapp.com  Fri Jun 11 03:00:19 2010
From: Naitik.Dani at netapp.com (Dani, Naitik)
Date: Thu, 10 Jun 2010 13:00:19 -0400
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <20100609234008.GF30208@linux55.nas.nasa.gov>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609173625.GD30208@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D707C@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609234008.GF30208@linux55.nas.nasa.gov>
Message-ID: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D7360@RTPMVEXC1-PRD.hq.netapp.com>

Iain,

Thanks for your previous reply. I have removed -n option as you asked
for and it worked.

Is there any link which explains how the key/certificate exchange take
place (i.e. architecture over view) for Certificate based SSH
authentication?

I would really like to understand the steps that occur when a client
tries to connect to a remote host using certificate.

Once again thanks for helping me with this.

1) ssh-keygen -f ca_rsa    --> Generates CA key for signing

2) ssh-keygen --> Generates the user key with the default name
(id_rsa/.pub)

3) ssh-keygen -s ca_rsa -I 2 /u/naitik/.ssh/id_rsa.pub  --> Signs the
user key with CA key
Signed user key /u/naitik/.ssh/id_rsa-cert.pub: id "2" valid forever

4) ssh-keygen -Lf /u/naitik/.ssh/id_rsa-cert.pub --> Prints the contents
of certificate
/u/naitik/.ssh/id_rsa-cert.pub:
        RSA-CERT user certificate
8c:50:f7:43:0a:ef:b3:8e:a9:4e:3f:04:d6:e7:a9:9a
        Signed by RSA CA ad:82:20:d2:17:f9:09:cb:10:4c:a9:f7:d2:07:7a:e6
        Key ID "2"
        Valid: forever
        Principals: (none)
        Constraints:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

5) cp ca_rsa.pub /u/naitik/.ssh/authorized_keys

6) Add cert-authority Tag
less authorized_keys
cert-authority ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCnI29TpnhPWSCGQdESr1gyCO3u5bKpm5aZ00TlLEli
wz9NaBkwEgIB2oYmILzrqMUI/HdjXH/keBd0acyvJ41jL7dATA0N
gipNs6O+Zka2ryKsHD9IlfMCTRVXj6/fB4fXmNue6KQmsbVNaZ/Vh2OuHFNr1SJsoHsbXchQ
mz+jEN2/yM8f8VJBwi02rz4BLFwijEcUFcj3cKm+PVGX3WT9JhAzgHVPZ4tnIorQeb1BRwN0
mMR
Zbh8710Uh7VfJyxN8VXaxfpwphHJVybfkMCMCcpT1vl2KhkmszGg3sAiSVs6BeeLgifXF62q
lfGW9VfGXyic+L/ohhDSkaN0AI3t9 root at naitik001 <mailto:root at naitik001> 



Naitik Dani
MTS
GX Infrastructure HQ

NetApp
724-741-5153 Direct
Naitik.Dani at netapp.com
www.netapp.com





> -----Original Message-----
> From: Iain Morgan [mailto:imorgan at nas.nasa.gov
<mailto:imorgan at nas.nasa.gov> ]
> Sent: Wednesday, June 09, 2010 19:40
> To: Dani, Naitik
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: X509 based certificate authentication in OpenSSH
>
> On Wed, Jun 09, 2010 at 15:09:49 -0500, Dani, Naitik wrote:
> > > particular, there is no need to copy it to remote hosts. You
> > > would only
> > > need to copy the public key, user_key.pub, to servers that do not
> > > support the certificate format, i.e. any older than
> OpenSSH 5.4 or any
> > > server using something other than OpenSSH. And you should
> _never_ copy
> > > the private key to a remote host.
> >
> > Does this mean that, if my servers do support certificate
> format, i.e.
> > newer than OpenSSH 5.4, then I need to copy user_key-cert.pub into
> > ~/.ssh/authorized_keys instead of user_key.pub?
>
> No, you _never_ need to add your *-cert.pub file to the
> ~/.ssh/authorized_keys file. You _only_ need to add the
> ca_key.pub file
> with the cert-authority tag. That allows the server to
> detemine that the
> certificate (which the client offers during authentication)
> is signed by
> a trusted CA.
>
> >
> > I tried that, and the connection failed. Is this the
> expected behavior
> > or am I missing something?
> >
> > Thanks
> >
>
> Offhand, I'm not sure what the expected behaviour would be if
> you added
> user_key-cert.pub to your authorized_keys file.  However, it would not
> be of any benefit.
>
> You may want to try using -v with ssh to see what actually is
> happening.
> I suspect that either ssh is not actually using the
> certificate or that
> you have a list of principals specified which does not match
> the account
> you are trying to authenticate to.
>
> You might also want to do 'ssh-keygen -Lf user_key-cert.pub' to verify
> the parameters that are set for the certificate.
>
> If those steps don't shed any light and you have sufficient access to
> the server, you could check the system logs for further info regarding
> the authentication attempt. For best results, you may need to set the
> LogLevel on the server to 'verbose.'
>
> --
> Iain Morgan
> 


From imorgan at nas.nasa.gov  Fri Jun 11 03:29:16 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 10 Jun 2010 10:29:16 -0700
Subject: X509 based certificate authentication in OpenSSH
In-Reply-To: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D7360@RTPMVEXC1-PRD.hq.netapp.com>
References: <DC931D7F7DCAEE47A56B9A4C2F2F0F9D081A62A6@RTPMVEXC1-PRD.hq.netapp.com>
	<20100607232252.GG19561@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D6ECF@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609173625.GD30208@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D707C@RTPMVEXC1-PRD.hq.netapp.com>
	<20100609234008.GF30208@linux55.nas.nasa.gov>
	<DC931D7F7DCAEE47A56B9A4C2F2F0F9D082D7360@RTPMVEXC1-PRD.hq.netapp.com>
Message-ID: <20100610172916.GG30208@linux55.nas.nasa.gov>

Hi Naitik,

You may want to look at PROTOCOL.certkeys in the OpenSSH source
distribution and at the archive for this mailing list. (www.marc.info is
a good place for the latter.) The call for release testing for the 5.4
release has an overview of the certificate support. And, of course, the
the source code, particularly auth2-pubkey.c, may be of interest.

On Thu, Jun 10, 2010 at 12:00:19 -0500, Dani, Naitik wrote:
> Iain,
> 
> Thanks for your previous reply. I have removed -n option as you asked for and it worked.
> 
> Is there any link which explains how the key/certificate exchange take place (i.e. architecture over view) for Certificate based SSH authentication?
> 
> I would really like to understand the steps that occur when a client tries to connect to a remote host using certificate.
> 
> Once again thanks for helping me with this.
> 
> 1) ssh-keygen -f ca_rsa    --> Generates CA key for signing
> 
> 2) ssh-keygen --> Generates the user key with the default name (id_rsa/.pub)
> 
> 3) ssh-keygen -s ca_rsa -I 2 /u/naitik/.ssh/id_rsa.pub  --> Signs the user key with CA key
> Signed user key /u/naitik/.ssh/id_rsa-cert.pub: id "2" valid forever
> 
> 4) ssh-keygen -Lf /u/naitik/.ssh/id_rsa-cert.pub --> Prints the contents of certificate
> /u/naitik/.ssh/id_rsa-cert.pub:
>         RSA-CERT user certificate 8c:50:f7:43:0a:ef:b3:8e:a9:4e:3f:04:d6:e7:a9:9a
>         Signed by RSA CA ad:82:20:d2:17:f9:09:cb:10:4c:a9:f7:d2:07:7a:e6
>         Key ID "2"
>         Valid: forever
>         Principals: (none)
>         Constraints:
>                 permit-X11-forwarding
>                 permit-agent-forwarding
>                 permit-port-forwarding
>                 permit-pty
>                 permit-user-rc
> 
> 5) cp ca_rsa.pub /u/naitik/.ssh/authorized_keys
> 
> 6) Add cert-authority Tag
> less authorized_keys
> cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnI29TpnhPWSCGQdESr1gyCO3u5bKpm5aZ00TlLEliwz9NaBkwEgIB2oYmILzrqMUI/HdjXH/keBd0acyvJ41jL7dATA0N
> gipNs6O+Zka2ryKsHD9IlfMCTRVXj6/fB4fXmNue6KQmsbVNaZ/Vh2OuHFNr1SJsoHsbXchQmz+jEN2/yM8f8VJBwi02rz4BLFwijEcUFcj3cKm+PVGX3WT9JhAzgHVPZ4tnIorQeb1BRwN0mMR
> Zbh8710Uh7VfJyxN8VXaxfpwphHJVybfkMCMCcpT1vl2KhkmszGg3sAiSVs6BeeLgifXF62qlfGW9VfGXyic+L/ohhDSkaN0AI3t9 root at naitik001<mailto:root at naitik001>
> 
> Naitik Dani
> MTS
> GX Infrastructure HQ
> 
> NetApp
> 724-741-5153 Direct
> Naitik.Dani at netapp.com
> www.netapp.com
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Iain Morgan [mailto:imorgan at nas.nasa.gov]
> > Sent: Wednesday, June 09, 2010 19:40
> > To: Dani, Naitik
> > Cc: openssh-unix-dev at mindrot.org
> > Subject: Re: X509 based certificate authentication in OpenSSH
> >
> > On Wed, Jun 09, 2010 at 15:09:49 -0500, Dani, Naitik wrote:
> > > > particular, there is no need to copy it to remote hosts. You
> > > > would only
> > > > need to copy the public key, user_key.pub, to servers that do not
> > > > support the certificate format, i.e. any older than
> > OpenSSH 5.4 or any
> > > > server using something other than OpenSSH. And you should
> > _never_ copy
> > > > the private key to a remote host.
> > >
> > > Does this mean that, if my servers do support certificate
> > format, i.e.
> > > newer than OpenSSH 5.4, then I need to copy user_key-cert.pub into
> > > ~/.ssh/authorized_keys instead of user_key.pub?
> >
> > No, you _never_ need to add your *-cert.pub file to the
> > ~/.ssh/authorized_keys file. You _only_ need to add the
> > ca_key.pub file
> > with the cert-authority tag. That allows the server to
> > detemine that the
> > certificate (which the client offers during authentication)
> > is signed by
> > a trusted CA.
> >
> > >
> > > I tried that, and the connection failed. Is this the
> > expected behavior
> > > or am I missing something?
> > >
> > > Thanks
> > >
> >
> > Offhand, I'm not sure what the expected behaviour would be if
> > you added
> > user_key-cert.pub to your authorized_keys file.  However, it would not
> > be of any benefit.
> >
> > You may want to try using -v with ssh to see what actually is
> > happening.
> > I suspect that either ssh is not actually using the
> > certificate or that
> > you have a list of principals specified which does not match
> > the account
> > you are trying to authenticate to.
> >
> > You might also want to do 'ssh-keygen -Lf user_key-cert.pub' to verify
> > the parameters that are set for the certificate.
> >
> > If those steps don't shed any light and you have sufficient access to
> > the server, you could check the system logs for further info regarding
> > the authentication attempt. For best results, you may need to set the
> > LogLevel on the server to 'verbose.'
> >
> > --
> > Iain Morgan
> >

-- 
Iain Morgan

From djm at mindrot.org  Fri Jun 11 21:57:08 2010
From: djm at mindrot.org (Damien Miller)
Date: Fri, 11 Jun 2010 21:57:08 +1000 (EST)
Subject: Question about host certificates
In-Reply-To: <20100604221228.GA5299@linux55.nas.nasa.gov>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
Message-ID: <alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>

On Fri, 4 Jun 2010, Iain Morgan wrote:

> Hi Damine,
> 
> If possible, I would prefer hostname or CIDR support. In either case, it
> might be worthwhile to use addr_match_list() instead of match_hostname()
> to handle the (admittedly rare) case where an explicit IP address is
> used on the command-line.
> 
> Yet another approach occurred to me recently. It would not be a complete
> solution but would have the virtue of being simple and could address
> (for the most part) environments such as compute clusters: Generalize
> the HostName directive. In particular, add support for a %h macro. That
> would allow something like this in ~/.ssh/config:
> 
> Host foo bar baz quux
> 	HostName	%h.example.com
> 
> In cases where the list of unqualified hostnames can easily be
> enumerated or match a convenient pattern, this could be a solution.

I'd like to do CIDR matching in ssh_config, but it is tricky and might turn
out to be too confusing to be practical. On the other hand, your idea is
simple and could work so here is a patch :)

Index: ssh.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh.c,v
retrieving revision 1.338
diff -u -p -r1.338 ssh.c
--- ssh.c	16 May 2010 12:55:51 -0000	1.338
+++ ssh.c	11 Jun 2010 11:56:35 -0000
@@ -663,6 +663,11 @@ main(int ac, char **av)
 		options.port = sp ? ntohs(sp->s_port) : SSH_DEFAULT_PORT;
 	}
 
+	if (options.hostname != NULL) {
+		host = percent_expand(options.hostname,
+		    "h", host, (char *)NULL);
+	}
+
 	if (options.local_command != NULL) {
 		char thishost[NI_MAXHOST];
 
@@ -672,15 +677,11 @@ main(int ac, char **av)
 		debug3("expanding LocalCommand: %s", options.local_command);
 		cp = options.local_command;
 		options.local_command = percent_expand(cp, "d", pw->pw_dir,
-		    "h", options.hostname? options.hostname : host,
-                    "l", thishost, "n", host, "r", options.user, "p", buf,
-                    "u", pw->pw_name, (char *)NULL);
+		    "h", host, "l", thishost, "n", host, "r", options.user,
+		    "p", buf, "u", pw->pw_name, (char *)NULL);
 		debug3("expanded LocalCommand: %s", options.local_command);
 		xfree(cp);
 	}
-
-	if (options.hostname != NULL)
-		host = options.hostname;
 
 	/* force lowercase for hostkey matching */
 	if (options.host_key_alias != NULL) {
Index: ssh_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v
retrieving revision 1.133
diff -u -p -r1.133 ssh_config.5
--- ssh_config.5	16 Apr 2010 06:45:01 -0000	1.133
+++ ssh_config.5	11 Jun 2010 11:56:36 -0000
@@ -526,6 +526,10 @@ or for multiple servers running on a sin
 .It Cm HostName
 Specifies the real host name to log into.
 This can be used to specify nicknames or abbreviations for hosts.
+If the hostname contains the character sequence
+.Ql %h ,
+then this will be replaced with the host name specified on the commandline
+(this is useful for manipulating unqualified names).
 The default is the name given on the command line.
 Numeric IP addresses are also permitted (both on the command line and in
 .Cm HostName

From imorgan at nas.nasa.gov  Tue Jun 15 09:04:27 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 14 Jun 2010 16:04:27 -0700
Subject: Question about host certificates
In-Reply-To: <alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>
Message-ID: <20100614230427.GO30208@linux55.nas.nasa.gov>

On Fri, Jun 11, 2010 at 06:57:08 -0500, Damien Miller wrote:
> On Fri, 4 Jun 2010, Iain Morgan wrote:
> 
> > Hi Damine,
> > 
> > If possible, I would prefer hostname or CIDR support. In either case, it
> > might be worthwhile to use addr_match_list() instead of match_hostname()
> > to handle the (admittedly rare) case where an explicit IP address is
> > used on the command-line.
> > 
> > Yet another approach occurred to me recently. It would not be a complete
> > solution but would have the virtue of being simple and could address
> > (for the most part) environments such as compute clusters: Generalize
> > the HostName directive. In particular, add support for a %h macro. That
> > would allow something like this in ~/.ssh/config:
> > 
> > Host foo bar baz quux
> > 	HostName	%h.example.com
> > 
> > In cases where the list of unqualified hostnames can easily be
> > enumerated or match a convenient pattern, this could be a solution.
> 
> I'd like to do CIDR matching in ssh_config, but it is tricky and might turn
> out to be too confusing to be practical. On the other hand, your idea is
> simple and could work so here is a patch :)
> 

I agree that CIDR support in the ssh_config would be _very_ nice, but I
recognize that implementing it in a reasonable way could, as you said,
be tricky. 

Thanks for the patch. I had written something similar, except that I
didn't take into account the affect on LocalCommand. I haven't tested
your patch yet, but it should do the trick.

-- 
Iain Morgan

From hyc at symas.com  Tue Jun 15 09:10:10 2010
From: hyc at symas.com (Howard Chu)
Date: Mon, 14 Jun 2010 16:10:10 -0700
Subject: cooked mode sessions
Message-ID: <4C16B6D2.1060701@symas.com>

Picking up on a couple really old threads (e.g. 
http://osdir.com/ml/ietf.secsh/2001-09/msg00003.html ) I've finally gotten 
around to this. The EXTPROC support on Linux is missing, but you can find 
kernel patches for that here

http://lkml.org/lkml/2010/6/11/403

I've also fixed up the netkit telnet / telnetd code to work with EXTPROC / 
LINEMODE on Linux, those patches are here

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585527

These ssh patches are still not even half-baked, just a proof of concept to 
get feedback and guidance on what the right approach actually is. To get an 
idea of where it's coming from you should read RFC1184 which gives the Telnet 
LINEMODE spec. Since the ssh protocol doesn't have the Do/Dont/Will/Wont 
option negotiation of Telnet things are of course a bit different here.

Instead of explicit negotiation, the server assumes the client supports 
linemode if it includes an EXTPROC bit in its tty modes. I've added a new 
"tty-changed" channel message as well, for the server to send tty mode changes 
back to the client. The client will assume the server supports linemode if it 
sends tty-changed messages.

If the server reports that the session tty is in cooked mode (ICANON|ECHO) 
then the client will use the readline library to process input. This opens the 
possibility of doing full local editing with command history on the client. 
(Though I haven't enabled history yet in this patch.)

So far this is only working as expected for dumb programs that don't try to 
manipulate the tty modes. I'm working on some patches to the readline library 
so that it will leave the tty in cooked mode if it detects that EXTPROC is set 
on the tty. So a remote bash shell will defer all input processing to the 
local client. Will also be able to support command completion, if the tty 
session has VEOL set to <TAB>.

Right now the tty mode handling on the client is a mess, it will need to be 
rationalized somehow to work cleanly with older raw-mode-only servers along 
with the linemode servers.

Feedback and help would be greatly welcomed.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dif1.txt
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100614/8abe70cd/attachment.txt>

From djm at mindrot.org  Tue Jun 15 14:28:57 2010
From: djm at mindrot.org (Damien Miller)
Date: Tue, 15 Jun 2010 14:28:57 +1000 (EST)
Subject: Question about host certificates
In-Reply-To: <20100614230427.GO30208@linux55.nas.nasa.gov>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>
	<20100614230427.GO30208@linux55.nas.nasa.gov>
Message-ID: <alpine.BSO.2.00.1006151419080.28567@fuyu.mindrot.org>

On Mon, 14 Jun 2010, Iain Morgan wrote:

> > I'd like to do CIDR matching in ssh_config, but it is tricky and might turn
> > out to be too confusing to be practical. On the other hand, your idea is
> > simple and could work so here is a patch :)
> 
> I agree that CIDR support in the ssh_config would be _very_ nice, but I
> recognize that implementing it in a reasonable way could, as you said,
> be tricky. 
> 
> Thanks for the patch. I had written something similar, except that I
> didn't take into account the affect on LocalCommand. I haven't tested
> your patch yet, but it should do the trick.

Another idea: use the struct addrinfo->ai_canonname filled in by
getaddrinfo with ai_hints = AI_CANONNAME as a potential match key.
On Linux and OpenBSD at least, this will append the domain name when
passed an unqualified name that is subsequently looked up by DNS.

It will also follow PTR records though, so it would be vulnerable to
DNS spoofing. I suppose once could add a heuristic that it is only used
IFF the original hostname is unqualified AND matches the first component
of the qualified hostname returned via AI_CANONNAME but that seems a
little hacky...

I wish there was some simple way to get feedback from the resolver as to
which DNS suffix was actually used to resolve an unqualified name. Anyone?

-d

From andreas at zzlevo.net  Wed Jun 16 03:53:28 2010
From: andreas at zzlevo.net (Andreas Gunnarsson)
Date: Tue, 15 Jun 2010 19:53:28 +0200
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
References: <AANLkTildoah3x0Gl7yctc9Gpqu-O5RGnIH_FJokJjFlH@mail.gmail.com>
Message-ID: <20100615175328.GA1950@zzlevo.net>

On Tue, Jun 08, 2010 at 12:58:51PM -0600, Jeremy Nickurak wrote:
> Is there anywhere to track progress on this issue? It'd be a fantastic
> feature that would fix all sorts of problems I deal with regularly.

The patch should be fully functional so anyone can apply it and use it.
It's a patch against the OpenBSD version but I don't think it would too
much work to adapt it for the portable version.

> You may also be interested in an article "Design and Implementation of
> a Mobile SSH Protocol", if you haven't seen it, since that team
> implemented (afaict) the same feature, whether or not it's related to
> the existing implementation...

I found some web pages mentioning it but I didn't find the paper itself
so I can't comment on how that design differs from the AppGate based
patch.

   Andreas

From andreas at zzlevo.net  Wed Jun 16 04:04:47 2010
From: andreas at zzlevo.net (Andreas Gunnarsson)
Date: Tue, 15 Jun 2010 20:04:47 +0200
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <20100609230526.GI19561@linux55.nas.nasa.gov>
References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly>
	<20100419192343.GA26131@zzlevo.net>
	<20100609230526.GI19561@linux55.nas.nasa.gov>
Message-ID: <20100615180447.GB1950@zzlevo.net>

On Wed, Jun 09, 2010 at 04:05:26PM -0700, Iain Morgan wrote:
> The recent discussion on this thread reminded me that I had intended to
> take a look at your patch. ;-)

Great, let me know if you find any problems.

> One solution would be to add the ability for ssh to automatically
> resume the session.

Yes, that shouldn't be too difficult to add. E.g. an option that
specifies the interval for retrying to resume when the session is
suspended.

> An alternative would be to add a 'resume' command to ssh's -O option.

Yes, being able to send suspend and resume commands to the master
process could be useful. That makes it possible to do a controlled
suspend before switching IP address.

> Perhaps the -O support is already there, but I did not see it during my
> cursory skim of the man page updates in the patch.

It's not in the patch which was mentioned on this list. I don't want it
to be a moving target so I'm not going to add any features to it until
it's been audited and accepted. But please feel free to enhance it and
it can be added when/if this patch is committed.

/Andreas

From jeremy at nickurak.ca  Wed Jun 16 04:09:56 2010
From: jeremy at nickurak.ca (Jeremy Nickurak)
Date: Tue, 15 Jun 2010 12:09:56 -0600
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <20100615180447.GB1950@zzlevo.net>
References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly>
	<20100419192343.GA26131@zzlevo.net>
	<20100609230526.GI19561@linux55.nas.nasa.gov>
	<20100615180447.GB1950@zzlevo.net>
Message-ID: <AANLkTikvwA-73z54dbpm6ZNnDlQnUkhIfxt2RDVLmqJa@mail.gmail.com>

On Tue, Jun 15, 2010 at 12:04, Andreas Gunnarsson <andreas at zzlevo.net> wrote:
>> An alternative would be to add a 'resume' command to ssh's -O option.
>
> Yes, being able to send suspend and resume commands to the master
> process could be useful. That makes it possible to do a controlled
> suspend before switching IP address.

Not helpful when your IP changes without your intervention. :)

The use case I'm thinking of is SSH on a mobile device, say a netbook
or phone, where you're moving ad-hoc between different wired and/or
wireless networks, getting a different IP every time.

I'd suggest that a robust solution should probably work even when the
TCP connection is lost for any reason (with the possible exception of
an explicit close).

-- 
Jeremy Nickurak -= Email/XMPP: jeremy at nickurak.ca =-

From andreas at zzlevo.net  Wed Jun 16 04:30:29 2010
From: andreas at zzlevo.net (Andreas Gunnarsson)
Date: Tue, 15 Jun 2010 20:30:29 +0200
Subject: OpenSSH with "resumable" functionality
In-Reply-To: <AANLkTikvwA-73z54dbpm6ZNnDlQnUkhIfxt2RDVLmqJa@mail.gmail.com>
References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly>
	<20100419192343.GA26131@zzlevo.net>
	<20100609230526.GI19561@linux55.nas.nasa.gov>
	<20100615180447.GB1950@zzlevo.net>
	<AANLkTikvwA-73z54dbpm6ZNnDlQnUkhIfxt2RDVLmqJa@mail.gmail.com>
Message-ID: <20100615183029.GC1950@zzlevo.net>

On Tue, Jun 15, 2010 at 12:09:56PM -0600, Jeremy Nickurak wrote:
> The use case I'm thinking of is SSH on a mobile device, say a netbook
> or phone, where you're moving ad-hoc between different wired and/or
> wireless networks, getting a different IP every time.
> 
> I'd suggest that a robust solution should probably work even when the
> TCP connection is lost for any reason (with the possible exception of
> an explicit close).

It does work when the connection is lost, and both sides will resend any
data that wasn't processed by the peer. The only requirement is that the
ssh client and server processes are still running.

However, there may be circumstances when it's better to actively suspend
the connection. For example, if the default route moves to another
interface it could take some time before it is possible to detect that
the TCP session is dead.

/Andreas

From imorgan at nas.nasa.gov  Wed Jun 16 08:01:03 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 15 Jun 2010 15:01:03 -0700
Subject: Question about host certificates
In-Reply-To: <alpine.BSO.2.00.1006151419080.28567@fuyu.mindrot.org>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>
	<20100614230427.GO30208@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006151419080.28567@fuyu.mindrot.org>
Message-ID: <20100615220102.GR30208@linux55.nas.nasa.gov>

On Mon, Jun 14, 2010 at 23:28:57 -0500, Damien Miller wrote:
> On Mon, 14 Jun 2010, Iain Morgan wrote:
> 
> > > I'd like to do CIDR matching in ssh_config, but it is tricky and might turn
> > > out to be too confusing to be practical. On the other hand, your idea is
> > > simple and could work so here is a patch :)
> > 
> > I agree that CIDR support in the ssh_config would be _very_ nice, but I
> > recognize that implementing it in a reasonable way could, as you said,
> > be tricky. 
> > 
> > Thanks for the patch. I had written something similar, except that I
> > didn't take into account the affect on LocalCommand. I haven't tested
> > your patch yet, but it should do the trick.
> 
> Another idea: use the struct addrinfo->ai_canonname filled in by
> getaddrinfo with ai_hints = AI_CANONNAME as a potential match key.
> On Linux and OpenBSD at least, this will append the domain name when
> passed an unqualified name that is subsequently looked up by DNS.

I haven't tested it, but it looks like AI_CANONNAME should also work on
Solaris and AIX.

> 
> It will also follow PTR records though, so it would be vulnerable to
> DNS spoofing. I suppose once could add a heuristic that it is only used
> IFF the original hostname is unqualified AND matches the first component
> of the qualified hostname returned via AI_CANONNAME but that seems a
> little hacky...

Does it only follow PTR records if the first argument is an explicit IP
address? If so, we could test whether the supplied hostname is really an
IP address and skip setting AI_CANONNAME.

> 
> I wish there was some simple way to get feedback from the resolver as to
> which DNS suffix was actually used to resolve an unqualified name. Anyone?
> 
> -d

-- 
Iain Morgan

From hyc at symas.com  Wed Jun 16 11:50:03 2010
From: hyc at symas.com (Howard Chu)
Date: Tue, 15 Jun 2010 18:50:03 -0700
Subject: cooked mode sessions
In-Reply-To: <4C16B6D2.1060701@symas.com>
References: <4C16B6D2.1060701@symas.com>
Message-ID: <4C182DCB.7070503@symas.com>

Howard Chu wrote:
> So far this is only working as expected for dumb programs that don't try to
> manipulate the tty modes. I'm working on some patches to the readline library
> so that it will leave the tty in cooked mode if it detects that EXTPROC is set
> on the tty. So a remote bash shell will defer all input processing to the
> local client. Will also be able to support command completion, if the tty
> session has VEOL set to<TAB>.

Simple patch for bash/readline here

http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/a34500e79021003b#

> Right now the tty mode handling on the client is a mess, it will need to be
> rationalized somehow to work cleanly with older raw-mode-only servers along
> with the linemode servers.
>
> Feedback and help would be greatly welcomed.

If anyone is interested, you can just follow along on this repo:

git://github.com/hyc/OpenSSH-LINEMODE.git

Everything should work exactly as before when connecting to an unpatached 
server. With a patched server and patched shell you'll have local editing plus 
command history. I'm still working out how to pass-thru the command completion 
bits.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From djm at mindrot.org  Wed Jun 16 12:31:12 2010
From: djm at mindrot.org (Damien Miller)
Date: Wed, 16 Jun 2010 12:31:12 +1000 (EST)
Subject: Question about host certificates
In-Reply-To: <20100615220102.GR30208@linux55.nas.nasa.gov>
References: <20100318221731.GA16369@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1003190929550.20987@fuyu.mindrot.org>
	<20100604221228.GA5299@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006112155220.25495@fuyu.mindrot.org>
	<20100614230427.GO30208@linux55.nas.nasa.gov>
	<alpine.BSO.2.00.1006151419080.28567@fuyu.mindrot.org>
	<20100615220102.GR30208@linux55.nas.nasa.gov>
Message-ID: <alpine.BSO.2.00.1006161225440.9253@fuyu.mindrot.org>

On Tue, 15 Jun 2010, Iain Morgan wrote:

> > It will also follow PTR records though, so it would be vulnerable to
> > DNS spoofing. I suppose once could add a heuristic that it is only used
> > IFF the original hostname is unqualified AND matches the first component
> > of the qualified hostname returned via AI_CANONNAME but that seems a
> > little hacky...
> 
> Does it only follow PTR records if the first argument is an explicit IP
> address? If so, we could test whether the supplied hostname is really an
> IP address and skip setting AI_CANONNAME.

oops, I meant CNAME records and not PTR. E.g. resolving "www.mindrot.org"
with AI_CANONNAME returns "natsu.mindrot.org" in the ai_canonname field.

$ dig +short www.mindrot.org cname
natsu.mindrot.org.

My concern is that an adversary could spoof a DNS response and inject
their own hostname. They would be limited to a repertoire of hostnames
that are already trusted by certificate, but this could be used to
leverage one compromised hostkey + DNS injection into a MITM against any
certificate signed by a trusted CA.

I guess it is probably not a good idea for this reason :(

-d

From hyc at symas.com  Wed Jun 16 17:33:42 2010
From: hyc at symas.com (Howard Chu)
Date: Wed, 16 Jun 2010 00:33:42 -0700
Subject: cooked mode sessions
In-Reply-To: <4C182DCB.7070503@symas.com>
References: <4C16B6D2.1060701@symas.com> <4C182DCB.7070503@symas.com>
Message-ID: <4C187E56.9090700@symas.com>

Howard Chu wrote:
> Howard Chu wrote:
>> So far this is only working as expected for dumb programs that don't try to
>> manipulate the tty modes. I'm working on some patches to the readline library
>> so that it will leave the tty in cooked mode if it detects that EXTPROC is set
>> on the tty. So a remote bash shell will defer all input processing to the
>> local client. Will also be able to support command completion, if the tty
>> session has VEOL set to<TAB>.
>
> Simple patch for bash/readline here
>
> http://groups.google.com/group/gnu.bash.bug/browse_thread/thread/a34500e79021003b#
>
>> Right now the tty mode handling on the client is a mess, it will need to be
>> rationalized somehow to work cleanly with older raw-mode-only servers along
>> with the linemode servers.
>>
>> Feedback and help would be greatly welcomed.
>
> If anyone is interested, you can just follow along on this repo:
>
> git://github.com/hyc/OpenSSH-LINEMODE.git
>
> Everything should work exactly as before when connecting to an unpatached
> server. With a patched server and patched shell you'll have local editing plus
> command history. I'm still working out how to pass-thru the command completion
> bits.
>
Ugh. Except that this only works well for a single client; if you mux another 
session in everything breaks. The GNU readline library assumes it's only 
working with one display in one process; it doesn't work well trying to mux it 
across multiple ttys. Is there a particular reason why the muxing code didn't 
just relay the session data from the master to the slave client, rather than 
passing file descriptors to the master and having it write directly to the 
slave's tty? I guess it saves on memory copies, but it also limits the other 
clients.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From philipp.marek at linbit.com  Wed Jun 16 17:55:27 2010
From: philipp.marek at linbit.com (Philipp Marek)
Date: Wed, 16 Jun 2010 09:55:27 +0200
Subject: LPK integration - summary and ideas
In-Reply-To: <195922799.689511276178622300.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
References: <195922799.689511276178622300.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <201006160955.28360.philipp.marek@linbit.com>

Hello everybody,

On Thursday 10 June 2010, Jan Chadima wrote:
> please look at
> https://bugzilla.mindrot.org/show_bug.cgi?id=1663
> there is a patch solving the above requests
> + some ldap backend also
Is there a way to get an ACK (or an NAK accompanied with an explanation what 
should be changed)?

Of course, getting that into mainline would be preferable; but if there's at 
least a qualified OK for the patch (regarding security), we could ask the 
distributions to pick it up.


Regards,

Phil


From hyc at symas.com  Thu Jun 17 10:01:00 2010
From: hyc at symas.com (Howard Chu)
Date: Wed, 16 Jun 2010 17:01:00 -0700
Subject: Small bug in mux_master_read_cb()
Message-ID: <4C1965BC.80604@symas.com>

I'm looking at the code from CVS as of May 21. The statement to allocate the 
mux state is allocating the size of a pointer, instead of the size of the 
struct being pointed to. The bug is benign in the original code because the 
struct has only an int element inside it, but it would corrupt memory if the 
struct were to be extended.

Simple fix here:

diff --git a/mux.c b/mux.c
index 3f5babc..f151021 100644
--- a/mux.c
+++ b/mux.c
@@ -931,7 +976,7 @@ mux_master_read_cb(Channel *c)

     /* Setup ctx and  */
     if (c->mux_ctx == NULL) {
-       state = xcalloc(1, sizeof(state));
+       state = xcalloc(1, sizeof(*state));
         c->mux_ctx = state;
         channel_register_cleanup(c->self,
             mux_master_control_cleanup_cb, 0);


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From hyc at symas.com  Thu Jun 17 10:33:45 2010
From: hyc at symas.com (Howard Chu)
Date: Wed, 16 Jun 2010 17:33:45 -0700
Subject: muxed client changes
In-Reply-To: <4C187E56.9090700@symas.com>
References: <4C16B6D2.1060701@symas.com> <4C182DCB.7070503@symas.com>
	<4C187E56.9090700@symas.com>
Message-ID: <4C196D69.4010003@symas.com>

Howard Chu wrote:
> Howard Chu wrote:
>> Everything should work exactly as before when connecting to an unpatached
>> server. With a patched server and patched shell you'll have local editing plus
>> command history. I'm still working out how to pass-thru the command completion
>> bits.
>>
> Ugh. Except that this only works well for a single client; if you mux another
> session in everything breaks. The GNU readline library assumes it's only
> working with one display in one process; it doesn't work well trying to mux it
> across multiple ttys. Is there a particular reason why the muxing code didn't
> just relay the session data from the master to the slave client, rather than
> passing file descriptors to the master and having it write directly to the
> slave's tty? I guess it saves on memory copies, but it also limits the other
> clients.

I've tweaked the mux framework to solve this:

Date:   Wed Jun 16 17:22:11 2010 -0700

     Add a new channel type for muxed clients.

     Previously the slave client process did nothing but wait for an
     exit message from the master. Now, it handles all terminal input
     and forwards the data to the master. This input is performed in
     the new SSH_CHANNEL_MUX_OPEN channel type in the slave process.
     The master still runs a regular SSH_CHANNEL_OPEN session to the
     remote host on behalf of the slave, and it still writes all of
     this channel output directly to the slave tty, but it no longer
     does any reading, and the channel's rfd is set to -1.

     Splitting things apart like this allows each session to operate
     their ttys independently without mixing up mode changes. It also
     allows the slave client to suspend itself on demand.

     Further additions to the mux framework include a WINCH message;
     the slave client handles its own SIGWINCH events and sends the
     data to the master, which forwards it to the remote host. This
     eliminates the need for the master to poll every session with
     TIOCGWINSZ and send size updates for every session at once.

     Also, to support readline, the master session has an output filter
     to search for a commandline prompt on the tail of the incoming
     data. This also gets sent from the master to the slave process.

     Likewise, tty-change messages received for the session are forwarded
     from the master to the slave process.

Something else I just noticed; the escape filter was broken anyway when muxed 
clients were around because it depended on a single last_was_cr flag, even 
though it could be processing input for many sessions in an interleaved order. 
As such it would fail to detect an escape character in a lot of situations 
where it should have seen it. That's fixed by splitting things up this way too.

Patches available here:  http://github.com/hyc/OpenSSH-LINEMODE

  channels.c   |   53 +++++++-----
  channels.h   |    4 +-
  clientloop.c |  199 ++++++++++++++++++++++++++++++++++++-------
  clientloop.h |    9 ++
  mux.c        |  271 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
  packet.c     |   12 +++
  packet.h     |    4 +-
  ttymodes.c   |   35 ++++----

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From djm at mindrot.org  Thu Jun 17 17:07:38 2010
From: djm at mindrot.org (Damien Miller)
Date: Thu, 17 Jun 2010 17:07:38 +1000 (EST)
Subject: Small bug in mux_master_read_cb()
In-Reply-To: <4C1965BC.80604@symas.com>
References: <4C1965BC.80604@symas.com>
Message-ID: <alpine.BSO.2.00.1006171707320.1638@fuyu.mindrot.org>

applied, thanks.

On Wed, 16 Jun 2010, Howard Chu wrote:

> I'm looking at the code from CVS as of May 21. The statement to allocate the
> mux state is allocating the size of a pointer, instead of the size of the
> struct being pointed to. The bug is benign in the original code because the
> struct has only an int element inside it, but it would corrupt memory if the
> struct were to be extended.
> 
> Simple fix here:
> 
> diff --git a/mux.c b/mux.c
> index 3f5babc..f151021 100644
> --- a/mux.c
> +++ b/mux.c
> @@ -931,7 +976,7 @@ mux_master_read_cb(Channel *c)
> 
>     /* Setup ctx and  */
>     if (c->mux_ctx == NULL) {
> -       state = xcalloc(1, sizeof(state));
> +       state = xcalloc(1, sizeof(*state));
>         c->mux_ctx = state;
>         channel_register_cleanup(c->self,
>             mux_master_control_cleanup_cb, 0);
> 
> 
> -- 
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From peter at stuge.se  Thu Jun 17 18:10:30 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 10:10:30 +0200
Subject: cooked mode sessions
In-Reply-To: <4C16B6D2.1060701@symas.com>
References: <4C16B6D2.1060701@symas.com>
Message-ID: <20100617081030.26799.qmail@stuge.se>

Howard Chu wrote:
> the client will use the readline library

How about libedit? I guess readline is not so hot in OpenSSH
upstream.


//Peter

From alon.barlev at gmail.com  Thu Jun 17 18:14:42 2010
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 17 Jun 2010 11:14:42 +0300
Subject: cooked mode sessions
In-Reply-To: <20100617081030.26799.qmail@stuge.se>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
Message-ID: <AANLkTikhkz-QbWbRaykZvqjJvdPn8l6-uRi34h54aWfr@mail.gmail.com>

libnoise is simple and  tiny...
Although not all functionality is there... :)

On Thu, Jun 17, 2010 at 11:10 AM, Peter Stuge <peter at stuge.se> wrote:
>
> Howard Chu wrote:
> > the client will use the readline library
>
> How about libedit? I guess readline is not so hot in OpenSSH
> upstream.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From alon.barlev at gmail.com  Thu Jun 17 18:15:00 2010
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 17 Jun 2010 11:15:00 +0300
Subject: cooked mode sessions
In-Reply-To: <AANLkTikhkz-QbWbRaykZvqjJvdPn8l6-uRi34h54aWfr@mail.gmail.com>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
	<AANLkTikhkz-QbWbRaykZvqjJvdPn8l6-uRi34h54aWfr@mail.gmail.com>
Message-ID: <AANLkTilkhLRiyyim3NVbJ1ouFQXnwr6g-hlrzpyF8-qF@mail.gmail.com>

Sorry, linenoise...

On Thu, Jun 17, 2010 at 11:14 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> libnoise is simple and ?tiny...
> Although not all functionality is there... :)
>
> On Thu, Jun 17, 2010 at 11:10 AM, Peter Stuge <peter at stuge.se> wrote:
>>
>> Howard Chu wrote:
>> > the client will use the readline library
>>
>> How about libedit? I guess readline is not so hot in OpenSSH
>> upstream.
>>
>>
>> //Peter
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From hyc at symas.com  Thu Jun 17 19:08:14 2010
From: hyc at symas.com (Howard Chu)
Date: Thu, 17 Jun 2010 02:08:14 -0700
Subject: cooked mode sessions
In-Reply-To: <AANLkTikhkz-QbWbRaykZvqjJvdPn8l6-uRi34h54aWfr@mail.gmail.com>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
	<AANLkTikhkz-QbWbRaykZvqjJvdPn8l6-uRi34h54aWfr@mail.gmail.com>
Message-ID: <4C19E5FE.5060200@symas.com>

Alon Bar-Lev wrote:
> libnoise is simple and  tiny...
> Although not all functionality is there... :)
>
> On Thu, Jun 17, 2010 at 11:10 AM, Peter Stuge<peter at stuge.se>  wrote:
>>
>> Howard Chu wrote:
>>> the client will use the readline library
>>
>> How about libedit? I guess readline is not so hot in OpenSSH
>> upstream.

Thanks for the suggestions, I hadn't seen these alternatives. I only started 
with readline since it's inside bash and I wanted to get bash to play along. 
linenoise looks promising since it's such a small library. Of course it also 
appears that it doesn't support any form of completion yet.

Command completion has turned out to be a bit tricky; I had first thought I 
could grab all of the completion possibilities out of band and feed them to 
the local readline library, but that's a waste. (After all, there are two 
goals here - one is moving more processing to the local client, but the other 
is to minimize network traffic.) Instead, I've opted to just forward any 
completion characters to the remote side, and let it deal with them if it can. 
This works, mostly, but it needs a bit more hacking to make sure it doesn't 
mess up and redraw the input line incorrectly.

There's another limitation that may be more annoying - you can't utilize any 
of the remote program's saved command history. Kind of raises a question about 
whether ssh itself should manage a persistent history, one for each 
hostname/destination.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From djm at mindrot.org  Thu Jun 17 19:11:21 2010
From: djm at mindrot.org (Damien Miller)
Date: Thu, 17 Jun 2010 19:11:21 +1000 (EST)
Subject: cooked mode sessions
In-Reply-To: <20100617081030.26799.qmail@stuge.se>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
Message-ID: <alpine.BSO.2.00.1006171910321.1638@fuyu.mindrot.org>

On Thu, 17 Jun 2010, Peter Stuge wrote:

> Howard Chu wrote:
> > the client will use the readline library
> 
> How about libedit? I guess readline is not so hot in OpenSSH
> upstream.

We already use libedit for sftp command editing and completion and we
would be loathe to add a dependency on another library that does something
similar.

-d

From hyc at symas.com  Thu Jun 17 19:19:54 2010
From: hyc at symas.com (Howard Chu)
Date: Thu, 17 Jun 2010 02:19:54 -0700
Subject: cooked mode sessions
In-Reply-To: <alpine.BSO.2.00.1006171910321.1638@fuyu.mindrot.org>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
	<alpine.BSO.2.00.1006171910321.1638@fuyu.mindrot.org>
Message-ID: <4C19E8BA.50208@symas.com>

Damien Miller wrote:
> On Thu, 17 Jun 2010, Peter Stuge wrote:
>
>> Howard Chu wrote:
>>> the client will use the readline library
>>
>> How about libedit? I guess readline is not so hot in OpenSSH
>> upstream.
>
> We already use libedit for sftp command editing and completion and we
> would be loathe to add a dependency on another library that does something
> similar.

That makes the choice easy then. I'll look into using libedit instead.
This page http://www.cs.utah.edu/~bigler/code/libedit.html implies that 
there's some doubt about which is the master source for libedit. Do you know 
where to get a current source that will run on Linux?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From hyc at symas.com  Thu Jun 17 19:34:55 2010
From: hyc at symas.com (Howard Chu)
Date: Thu, 17 Jun 2010 02:34:55 -0700
Subject: signals and RFC4254
Message-ID: <4C19EC3F.1090808@symas.com>

This may be more relevant to an IETF mailing list but I figured I'd start here 
first. I ran across this because signals need to be sent as explicit commands, 
not as special characters, when using EXTPROC. So I started implementing the 
"signal" channel request. However, the description of the request is inadequate.

RFC4254 section 6.9 says the 'signal name' values are the same as discussed in 
6.10 for the "exit-signal" message. But that list of signals is specifically 
limited to values that can cause a program to exit, and be returned in a 
program's exit status. This list of signals you can *receive* on exit is only 
a subset of the signals you might want to *send* with a "signal" channel 
request. In particular, if you want to support sending all of the signals that 
can be generated by keyboard input, the suspend character is missing (SIGTSTP).

I guess we can live without most of the others, but possibly SIGCONT and 
SIGSTOP might be useful too. I think TSTP should be part of the base spec, 
(and not an xx at foo.bar extension) otherwise this channel request can't fulfill 
the most basic need (propagating signals from a terminal to an app).
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From peter at stuge.se  Thu Jun 17 19:47:37 2010
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Jun 2010 11:47:37 +0200
Subject: cooked mode sessions
In-Reply-To: <4C19E8BA.50208@symas.com>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
	<alpine.BSO.2.00.1006171910321.1638@fuyu.mindrot.org>
	<4C19E8BA.50208@symas.com>
Message-ID: <20100617094737.12144.qmail@stuge.se>

Howard Chu wrote:
> I'll look into using libedit instead.
> This page http://www.cs.utah.edu/~bigler/code/libedit.html implies that 
> there's some doubt about which is the master source for libedit. Do you 
> know where to get a current source that will run on Linux?

Gentoo uses http://www.thrysoee.dk/editline/libedit-20090923-3.0.tar.gz


//Peter

From go2mars at yahoo.cn  Thu Jun 17 18:33:52 2010
From: go2mars at yahoo.cn (Go To Mars)
Date: Thu, 17 Jun 2010 16:33:52 +0800 (CST)
Subject: Help ME, Please
Message-ID: <365604.71694.qm@web92202.mail.cnh.yahoo.com>

I want to login in remote server, git server, with two accounts (mars and gitolite) without password. e.g. (steps)

1. ssh-keygen? # no password
2. scp .ssh/id_rsa.pub gitolite at gitserver:/tmp/
3. ssh gitolite at gitserve
4. cat /tmp/id_rsa.pub >> .ssh/authorized_keys
5. exit

Then, do :

ssh gitolite at gitserver ls 

But error message occurs:? 
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

However, when cat the id_rsa.pub to the end of mars account's .ssh/authorized_keys, that's OK. Why?

Please help me !

Thank you so much.




      

From cristian.ionescu-idbohrn at axis.com  Thu Jun 17 20:17:55 2010
From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn)
Date: Thu, 17 Jun 2010 12:17:55 +0200 (CEST)
Subject: cooked mode sessions
In-Reply-To: <4C19E8BA.50208@symas.com>
References: <4C16B6D2.1060701@symas.com> <20100617081030.26799.qmail@stuge.se>
	<alpine.BSO.2.00.1006171910321.1638@fuyu.mindrot.org>
	<4C19E8BA.50208@symas.com>
Message-ID: <1006171212480.5913@somehost>

On Thu, 17 Jun 2010, Howard Chu wrote:

> That makes the choice easy then. I'll look into using libedit
> instead. This page http://www.cs.utah.edu/~bigler/code/libedit.html
> implies that there's some doubt about which is the master source for
> libedit. Do you know where to get a current source that will run on
> Linux?

Debian (unstable) uses libedit (2.11-20080614-1) from
http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-5-0/src/lib/libedit/
with dependencies to libbsd and libncurses5.


Cheers,

-- 
Cristian

From vinschen at redhat.com  Fri Jun 18 00:48:54 2010
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 17 Jun 2010 16:48:54 +0200
Subject: [patch/cygwin]: Change to README file
Message-ID: <20100617144854.GN8163@calimero.vinschen.de>

Hi,

could somebody with checking rights please apply the below patch?
It's only a small fix to the README file to remove a reference
to the obsolete minires-devel package, and to add the reference
to the libedit-devel package since CYgwin now provides libedit as well.


Thanks,
Corinna


Index: contrib/cygwin/README
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/README,v
retrieving revision 1.16
diff -u -p -r1.16 README
--- contrib/cygwin/README	5 Mar 2005 00:20:40 -0000	1.16
+++ contrib/cygwin/README	17 Jun 2010 14:47:27 -0000
@@ -201,6 +201,7 @@ configure are used for the Cygwin binary
 	--mandir='${datadir}/man' \
 	--infodir='${datadir}/info'
 	--with-tcp-wrappers
+	--with-libedit
 
 If you want to create a Cygwin package, equivalent to the one
 in the Cygwin binary distribution, install like this:
@@ -217,11 +218,14 @@ You must have installed the following pa
 
 - zlib
 - openssl-devel
-- minires-devel
 
 If you want to build with --with-tcp-wrappers, you also need the package
 
 - tcp_wrappers
+
+If you want to build with --with-libedit, you also need the package
+
+- libedit-devel
 
 Please send requests, error reports etc. to cygwin at cygwin.com.
 

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From tim at multitalents.net  Fri Jun 18 04:12:46 2010
From: tim at multitalents.net (Tim Rice)
Date: Thu, 17 Jun 2010 11:12:46 -0700 (PDT)
Subject: [patch/cygwin]: Change to README file
In-Reply-To: <20100617144854.GN8163@calimero.vinschen.de>
References: <20100617144854.GN8163@calimero.vinschen.de>
Message-ID: <Pine.UW2.4.64.1006171111440.12532@server01.int.multitalents.net>

On Thu, 17 Jun 2010, Corinna Vinschen wrote:

> Hi,
> 
> could somebody with checking rights please apply the below patch?
> It's only a small fix to the README file to remove a reference
> to the obsolete minires-devel package, and to add the reference
> to the libedit-devel package since CYgwin now provides libedit as well.

Done.
 
> Thanks,
> Corinna
> 
> Index: contrib/cygwin/README
[snip]

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net



From arun.manthalkar at db.com  Sat Jun 19 01:54:08 2010
From: arun.manthalkar at db.com (Arun Manthalkar)
Date: Fri, 18 Jun 2010 17:54:08 +0200
Subject: OpenSSH -  SFTP issue
Message-ID: <OF5EB14E29.229A5ADF-ONC1257746.0056A514-C1257746.00575AB3@db.com>


   Hello,



   We are having issue with SFTP for Windows server. The OpenSSH reports
   the "Exit Staus -1" upon exiting the sftp session ( Though the file is
   successfully getting transferred!!). I have opened ticket with VanDyke
   Software - vShell and reported this issue. Accordiong to VanDyke
   Software, there is no issue with vShell configuration / its debug logs.

   Would you please let us know, what is this "Exit Status -1"?. Note that
   when transfering to Unix servers, it gives "Exit Status 0".



   Sample Log:
   debug3: channel 0: status: The following connections are open:
     #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

   debug3: channel 0: close_fds r -1 w -1 e 7
   debug1: fd 0 clearing O_NONBLOCK
   debug2: fd 1 is not O_NONBLOCK
   debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 2.5 seconds
   debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
   debug1: Exit status -1

   Please let me know if you need any more detials.

   Thanks & Regards
   -------------------------
   Arun Manthalkar
   GTO-Deutsche Asset management
   # 1, Beacon Street, 11th Floor
   Boston, MA - 02108
   Desk Phone       : +1-617-295-6084
   Email:   [1]arun.manthalkar at db.com
   ***********************************************************************
   **********
   This mail is transmitted to you on behalf of HCL Technologies.
   Diese Post wird Ihnen im Namen der HCL Technologies ubermittelt
   ***********************************************************************
   ***************

   --
   Informationen (einschlie?lich Pflichtangaben) zu einzelnen, innerhalb
   der EU t?tigen Gesellschaften und Zweigniederlassungen des Konzerns
   Deutsche Bank finden Sie unter
   http://www.deutsche-bank.de/de/content/pflichtangaben.htm. Diese E-Mail
   enth?lt vertrauliche und/ oder rechtlich gesch?tzte Informationen. Wenn
   Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich
   erhalten haben, informieren Sie bitte sofort den Absender und
   vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die
   unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
   Please refer to http://www.db.com/en/content/eu_disclosures.htm for
   information (including mandatory corporate particulars) on selected
   Deutsche Bank branches and group companies registered or incorporated
   in the European Union. This e-mail may contain confidential and/or
   privileged information. If you are not the intended recipient (or have
   received this e-mail in error) please notify the sender immediately and
   delete this e-mail. Any unauthorized copying, disclosure or
   distribution of the material in this e-mail is strictly forbidden.

References

   1. mailto:arun.manthalkar at db.com

From Shyamal_Pandya1 at symantec.com  Mon Jun 21 16:43:17 2010
From: Shyamal_Pandya1 at symantec.com (Shyamal Pandya1)
Date: Mon, 21 Jun 2010 12:13:17 +0530
Subject: FIPS patch for OpenSSH on RHEL 4?
Message-ID: <76D1B73C8A925F4E9334186339689B8A07949F7C@PUNAXCHCLUPIN05.enterprise.veritas.com>

Hi All,

 

Our requirement is to have OpenSSH with FIPS 140-2 support deployed on
RHEL 4.8 (going to RHEL 5 is not an option as of now). From the mailing
list I have found that FIPS patches are available for openssh 3.8p1, but
that is older than the openssh version (3.9 p1) that is bundled with
RHEL 4.8. FIPS support seems to be available on 5.3p1, however I am not
sure whether that can be  built and deployed over RHEL 4. 

 

My question is, what would be the latest openssh version to used over
RHEL 4.8 (kernel 2.6.9), and would that version have a FIPS patch
available? 

 

Appreciate the help,

Shyamal


From peter at stuge.se  Mon Jun 21 19:32:20 2010
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Jun 2010 11:32:20 +0200
Subject: FIPS patch for OpenSSH on RHEL 4?
In-Reply-To: <76D1B73C8A925F4E9334186339689B8A07949F7C@PUNAXCHCLUPIN05.enterprise.veritas.com>
References: <76D1B73C8A925F4E9334186339689B8A07949F7C@PUNAXCHCLUPIN05.enterprise.veritas.com>
Message-ID: <20100621093220.18563.qmail@stuge.se>

Shyamal Pandya1 wrote:
> what would be the latest openssh version to used over RHEL 4.8
> (kernel 2.6.9), and would that version have a FIPS patch available?

I believe the current OpenSSH code should work fine on Linux 2.6.9.
Why don't you try it out?

If you're looking for a solution that is supported by Red Hat, then
you'll have to talk to them, obviously.


//Peter

From Shyamal_Pandya1 at symantec.com  Mon Jun 21 20:01:20 2010
From: Shyamal_Pandya1 at symantec.com (Shyamal Pandya1)
Date: Mon, 21 Jun 2010 15:31:20 +0530
Subject: FIPS patch for OpenSSH on RHEL 4?
In-Reply-To: <20100621093220.18563.qmail@stuge.se>
References: <76D1B73C8A925F4E9334186339689B8A07949F7C@PUNAXCHCLUPIN05.enterprise.veritas.com>
	<20100621093220.18563.qmail@stuge.se>
Message-ID: <76D1B73C8A925F4E9334186339689B8A0794A039@PUNAXCHCLUPIN05.enterprise.veritas.com>

Does the current code have FIPS 140-mode support?

Thanks,
Shyamal

-----Original Message-----
From: openssh-unix-dev-bounces+shyamal_pandya1=symantec.com at mindrot.org
[mailto:openssh-unix-dev-bounces+shyamal_pandya1=symantec.com at mindrot.or
g] On Behalf Of Peter Stuge
Sent: Monday, June 21, 2010 3:02 PM
To: openssh-unix-dev at mindrot.org
Subject: Re: FIPS patch for OpenSSH on RHEL 4?

Shyamal Pandya1 wrote:
> what would be the latest openssh version to used over RHEL 4.8
> (kernel 2.6.9), and would that version have a FIPS patch available?

I believe the current OpenSSH code should work fine on Linux 2.6.9.
Why don't you try it out?

If you're looking for a solution that is supported by Red Hat, then
you'll have to talk to them, obviously.


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

From imorgan at nas.nasa.gov  Tue Jun 22 05:13:29 2010
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 21 Jun 2010 12:13:29 -0700
Subject: FIPS patch for OpenSSH on RHEL 4?
In-Reply-To: <76D1B73C8A925F4E9334186339689B8A0794A039@PUNAXCHCLUPIN05.enterprise.veritas.com>
References: <76D1B73C8A925F4E9334186339689B8A07949F7C@PUNAXCHCLUPIN05.enterprise.veritas.com>
	<20100621093220.18563.qmail@stuge.se>
	<76D1B73C8A925F4E9334186339689B8A0794A039@PUNAXCHCLUPIN05.enterprise.veritas.com>
Message-ID: <20100621191329.GA14083@linux55.nas.nasa.gov>

On Mon, Jun 21, 2010 at 05:01:20 -0500, Shyamal Pandya1 wrote:
> Does the current code have FIPS 140-mode support?
> 
> Thanks,
> Shyamal

No. If you search https://bugzilla.mindrot.org, you will see that there
are currently three open requests regarding FIPS support, bz#1197,
bz#1647, and bz#1701.

> 
> -----Original Message-----
> From: openssh-unix-dev-bounces+shyamal_pandya1=symantec.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+shyamal_pandya1=symantec.com at mindrot.or
> g] On Behalf Of Peter Stuge
> Sent: Monday, June 21, 2010 3:02 PM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: FIPS patch for OpenSSH on RHEL 4?
> 
> Shyamal Pandya1 wrote:
> > what would be the latest openssh version to used over RHEL 4.8
> > (kernel 2.6.9), and would that version have a FIPS patch available?
> 
> I believe the current OpenSSH code should work fine on Linux 2.6.9.
> Why don't you try it out?
> 
> If you're looking for a solution that is supported by Red Hat, then
> you'll have to talk to them, obviously.
> 
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

From advax at triumf.ca  Fri Jun 25 12:15:59 2010
From: advax at triumf.ca (Andrew Daviel)
Date: Thu, 24 Jun 2010 19:15:59 -0700 (PDT)
Subject: Compromised servers, SSH keys, and replay attacks
Message-ID: <Pine.LNX.4.64.1006241856090.23655@andrew.triumf.ca>


We had an incident recently where an openssh client and server were 
replaced with trojanned versions (it has SKYNET ASCII-art in the binary, 
if anyone's seen it. Anyone seen the source code ?). The trojan ssh & 
sshd both logged host/user/password, and probably had a login backdoor.

Someone asked me what was their exposure if they used public/private keys 
instead of passwords.

My suspicion is, for this particular trojan, zero.
But in general, I wondered what credentials could possibly be exposed to 
a modified SSH client or server.

I imagine, if the client is modified it could capture passphrases, and 
the private key (which could be in any case read from 
the filesystem of a rooted box), in addition to I/O on the user terminal.

If a server is modified, I'm not so sure. I don't believe it could access 
the passphrase which should never leave the client. I presume it could 
capture the public key, which could be read from the filesystem anyway.
And I presume it could capture traffic to/from the virtual terminal.

Is there any way for an attacker to replay authentication to a third 
machine, accessed via the compromised machine using ssh-agent ?

If a user connects to a compromised machine using keys, but from an 
untainted client, do they need to change their keys or passphrase ?

(I presume, in principle, that an attacker could steal private user keys 
and machine keys from a rooted server, then subvert the DNS and entice 
users to login to their own server instead. Though I'm not sure why 
they'd want to do that having got server root. Bypass a firewall, maybe.)

-- 
Andrew Daviel, TRIUMF, Canada

From openssh at tlinx.org  Fri Jun 25 12:05:27 2010
From: openssh at tlinx.org (L.A. Walsh)
Date: Thu, 24 Jun 2010 19:05:27 -0700
Subject: RFE:  add "AllowMultiUserPermissions" for .ssh/ files 
Message-ID: <4C240EE7.1090805@tlinx.org>

I have multiple logins that use common home files.  I'd like to be able to
use either acls to permit users specifically, or add a group with my 
users in it
to have access to my .ssh files and still have ssh work.

If I want to grant access to myself with multiple logins, to my own 
files, I shouldn't
have ssh disallowing my security policy on my systems.  To work around 
it I have
to have less secure workarounds that are a pain.  I'd live with some 
option that I
need to add to the config files to explicitly tell 'ssh' that I know 
what I am doing.

Would such an option be possible?
You can even name it "AllowInsecurePermissions" or something similar if you
feel it necessary to make it more explicit...  :-)

Thanks,
Linda


From djm at mindrot.org  Fri Jun 25 16:52:36 2010
From: djm at mindrot.org (Damien Miller)
Date: Fri, 25 Jun 2010 16:52:36 +1000 (EST)
Subject: Compromised servers, SSH keys, and replay attacks
In-Reply-To: <Pine.LNX.4.64.1006241856090.23655@andrew.triumf.ca>
References: <Pine.LNX.4.64.1006241856090.23655@andrew.triumf.ca>
Message-ID: <alpine.BSO.2.00.1006251431430.28786@fuyu.mindrot.org>

On Thu, 24 Jun 2010, Andrew Daviel wrote:

>
> We had an incident recently where an openssh client and server were
> replaced with trojanned versions (it has SKYNET ASCII-art in the
> binary, if anyone's seen it. Anyone seen the source code ?). The
> trojan ssh & sshd both logged host/user/password, and probably had a
> login backdoor.
>
> Someone asked me what was their exposure if they used public/private
> keys instead of passwords.
>
> My suspicion is, for this particular trojan, zero. But in general, I
> wondered what credentials could possibly be exposed to a modified SSH
> client or server.
>
> I imagine, if the client is modified it could capture passphrases, and
> the private key (which could be in any case read from the filesystem
> of a rooted box), in addition to I/O on the user terminal.

Correct.

> If a server is modified, I'm not so sure. I don't believe it could
> access the passphrase which should never leave the client. I presume
> it could capture the public key, which could be read from the
> filesystem anyway. And I presume it could capture traffic to/from the
> virtual terminal.

Correct. The passphrase and private key never leave the client. A
trojaned server could however silently accept authentication and then
try to phish a users for their private key passphrase by presenting a
fake "enter passphrase prompt".

> Is there any way for an attacker to replay authentication to a third
> machine, accessed via the compromised machine using ssh-agent ?

In SSHv2 it should be cryptographically impossible for a server to reply
a public key authentication to another server. In SSHv1 the guarantees
are quite a bit weaker, and it is probably possible for a hostile server
to replay authentication to another server *if* is has a copy of the
victim server's private host key.

> If a user connects to a compromised machine using keys, but from an
> untainted client, do they need to change their keys or passphrase ?

The big worry is whether the user has forwarded an agent to the
compromised server. If they have, then any host that trusts a key in
that agent may have been compromised too. Note that the attacker would
not have access the the private keys themselves (unless they broke into
the host where the agent is running or the private keys are stored), but
they would be able to use the keys in the agent for authentication. This
is why I like the "require confirmation" option for ssh-add.

If not, then changing their passphrase would probably be sufficient
prudence given the above phishing attack.

> (I presume, in principle, that an attacker could steal private user
> keys and machine keys from a rooted server, then subvert the DNS and
> entice users to login to their own server instead. Though I'm not sure
> why they'd want to do that having got server root. Bypass a firewall,
> maybe.)

They could create a server that accepts passwordless authentication and
then issues a password prompt to try and phish your password or private
key passphrase. Owning a server that users will connect to also exposes
any client-side bugs in ssh.

-d

From yanagisawa at csg.is.titech.ac.jp  Sat Jun 26 08:16:46 2010
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Sat, 26 Jun 2010 07:16:46 +0900
Subject: The Camellia block cipher for OpenSSH in OpenBSD
In-Reply-To: <20070715202450.bac928dc.yanagisawa@csg.is.titech.ac.jp>
References: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp>	<20070712183133.19444.qmail@cdy.org>	<4698B8E2.5050505@csg.is.titech.ac.jp>	<Pine.BSO.4.64.0707150741420.9737@fuyu.mindrot.org>
	<20070715202450.bac928dc.yanagisawa@csg.is.titech.ac.jp>
Message-ID: <4C252ACE.3030506@csg.is.titech.ac.jp>

Hi all,

I am afraid this mailing list is the correct mailing list to say, but I 
have implemented the patch to add support of the Camellia block cipher 
for OpenBSD's OpenSSH.  I put the patches at the Comment 8 and 9 of follows:
https://bugzilla.mindrot.org/show_bug.cgi?id=1340
Comment 8 is for OpenSSL to support Camellia and Comment 9 is for 
OpenSSH in OpenBSD to support Camellia.

I used to write the patch to portable OpenSSH, and was suggested to post 
the patch to OpenBSD.  Since OpenSSL in OpenBSD does not have a support 
for Camellia at that time, I just waited for it support the Camellia.

Will you review it?

Thank you in advance,
Yoshisato Yanagisawa.


From chckhelp at gmail.com  Mon Jun 28 19:19:17 2010
From: chckhelp at gmail.com (check help)
Date: Mon, 28 Jun 2010 12:19:17 +0300
Subject: hi
Message-ID: <AANLkTin_s0eHny0YKqD6MusfOtF-vMtUQLikEWMiWG24@mail.gmail.com>

hi

are you available i need your help


ty

From angusteno at gmail.com  Wed Jun 30 14:44:02 2010
From: angusteno at gmail.com (Angus Thorn)
Date: Wed, 30 Jun 2010 14:44:02 +1000
Subject: sshd
Message-ID: <AANLkTinelT0Lt61A9u-jHEYElX6iuuZv3LslQLQLcGHu@mail.gmail.com>

Hi

Dont know if its possible, can't find any info on the net, but i wanted to
stop my sshd server from returning authntication failed messages to the
clients. Example, a person tries to login and the user or password is
incorrect, i dont want the server to say 'Received disconnect from IP Too
many authentication failures for user'. Just return nothing as if its not
there.

Is there a setting in the sshd_config file? im running a x64 gentoo and
openssh 5.3_p1-r1



Cheers

Angus