From gdfuego at gmail.com  Fri Dec  2 03:17:10 2011
From: gdfuego at gmail.com (G. D. Fuego)
Date: Thu, 1 Dec 2011 11:17:10 -0500
Subject: Bad protocol version identification from UNKNOWN (patch)
Message-ID: <CALmbKGX1Kv5L2LbwVLLL7BhtoOXdAcn4fHJ6umcegaTgSPNYfA@mail.gmail.com>

I was just helping someone track down why they were getting a "Bad
protocol version identification" error for sshd, and I noticed that it
was logging that the connection was coming from UNKNOWN.

It looks like when this error condition is triggered, the socket is
closed and then the error is logged.  Unfortunately the logging calls
get_remote_ipaddr, which returns UNKNOWN if there is no socket.

The attached fix closes the socket after the logging is complete.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sshd-bad-protocol-logging.patch
Type: text/x-patch
Size: 557 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111201/6a92ed3a/attachment.bin>

From p.berndroth at philuweb.de  Tue Dec  6 06:38:03 2011
From: p.berndroth at philuweb.de (Philip Berndroth)
Date: Mon, 05 Dec 2011 20:38:03 +0100
Subject: AllowUsers
Message-ID: <4EDD1D9B.2090008@philuweb.de>

Hi guys,

i think, that we have found an issue in the config "sshd_config".

The correct way is, to set AllowUsers in the config like this:


> AllowUsers root at 10.10.10.10 user1 at 20.20.20.20 user2 at 30.30.30.30



In our case, users were separated with a comma. Our hoster has not 
followed the correct syntax.
After a reload of the ssh service no error was displayed, and the hoster 
thought that configuration was correct.

After a reload with the wrong syntax in config file, the service should 
issue an error and should not reload!

Server:
Ubuntu 10.04.3 LTS
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009


regards,
Philip Berndroth

philuweb.software


From imorgan at nas.nasa.gov  Tue Dec  6 10:42:50 2011
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 5 Dec 2011 15:42:50 -0800
Subject: Server moved
In-Reply-To: <alpine.BSO.2.00.1111281023090.25728@natsu.mindrot.org>
References: <alpine.BSO.2.00.1111281023090.25728@natsu.mindrot.org>
Message-ID: <20111205234250.GH5573@linux124.nas.nasa.gov>

On Sun, Nov 27, 2011 at 17:23:58 -0600, Damien Miller wrote:
> Hi,
> 
> The server move was completed over the weekend. Please let me know if
> anything is broken.
> 
> -d

Hi Damien,

I just noticed that the last snapshot at
http://www.mindrot.org/openssh_snap is from the 21st. I suspect that
this broke with the server move.

-- 
Iain Morgan

From stephen.farrell at cs.tcd.ie  Wed Dec  7 02:26:41 2011
From: stephen.farrell at cs.tcd.ie (Stephen Farrell)
Date: Tue, 06 Dec 2011 15:26:41 +0000
Subject: [saag] ssh-keygen -r should support SSHFP records for ECDSA (or
 at least return non-zero error code on failure)
In-Reply-To: <4ECCADE5.30708@cs.tcd.ie>
References: <4ECA6E4D.3030101@fifthhorseman.net>
 <98237.1322028405@eng-mail01.juniper.net> <4ECCADE5.30708@cs.tcd.ie>
Message-ID: <4EDE3431.6050403@cs.tcd.ie>


FYI - IETF last call for this has just gone out. [1]
Please comment on ietf at ietf.org if there are issues
that need to be raised.

Thanks,
Stephen.

[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09643.html

On 11/23/2011 08:25 AM, Stephen Farrell wrote:
>
> Thanks Mark,
>
> Yes, I'm happy to AD sponsor. No one objected when I asked
> before and it seems quite reasonable.
>
> Ond?ej - I'll start an IETF LC since there only seem to be
> typos to be fixed.
>
> Cheers,
> S.
>
> On 11/23/2011 06:06 AM, Mark D. Baushke wrote:
>> Hi Daniel,
>>
>> Daniel Kahn Gillmor<dkg at fifthhorseman.net> writes:
>>
>>> hi folks:
>>>
>>> it looks like ssh-keygen -r can't export SSHFP records for ECDSA keys:
>>>
>>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P ''
>>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub
>>> export_dns_rr: unsupported algorithm
>>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$
>>>
>>> the first number in my prompt is the return code of the last command;
>>> note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it
>>> returns 0.
>>>
>>> at the least, it should return non-zero on failure.
>>>
>>>
>>> I note that the relevant RFC doesn't include an enumeration for ECDSA:
>>>
>>> https://tools.ietf.org/html/rfc4255#section-3.1.1
>>>
>>> Could anyone on this list kick off the IETF process for allocating a new
>>> ID in that registry for ECDSA? I'm not currently involved in the IETF's
>>> Network Working Group so i don't really know the political landscape
>>> there.
>>
>> I believe that the SSH development community will need to support this
>> effort:
>>
>> http://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2-00
>>
>> which specifies values for both the ECDSA algorithm and a SHA-256
>> fingerprint algorithm.
>>
>> RFC 4255 enumerates the RSA and DSS algorithms and the SHA-1 fingerprint
>> type.
>>
>> draft-os-ietf-sshfp-ecdsa-sha2-00 authored by O. Sury has a typo in the
>> draft suggesting that they update RFC 4225 which is wrong, but it seems
>> to be a simple typo as the body of the draft referecnes RFC 4255.
>>
>> However, it does add ECDSA to the SSHFP RR types and SHA-256 to the
>> fingerprint types.
>>
>> The draft expires on Dec 18, 2011.
>>
>> This draft was sent to saag at ietf.org and the author also wrote a patch
>> for OpenSSH (portable) in
>>
>> https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch
>>
>>
>> See the message thread here:
>>
>> http://www.ietf.org/mail-archive/web/saag/current/msg03326.html
>> http://www.ietf.org/mail-archive/web/saag/current/msg03327.html
>>
>> Stephen Farrell<stephen.farrell at cs.tcd.ie> says that the author is
>> asking the AD to sponsor the work. And Warren Kumari<warren at kumari.net>
>> has added his support.
>>
>> This seems like something that should be raised on the
>> ietf-ssh at NetBSD.org list with a CC to saag at ietf.org, so
>> I have added these to lists to my response to this message.
>>
>> For the record, my vote is +1 for this draft.
>>
>> -- Mark
>> _______________________________________________
>> saag mailing list
>> saag at ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
> _______________________________________________
> saag mailing list
> saag at ietf.org
> https://www.ietf.org/mailman/listinfo/saag

From djm at mindrot.org  Wed Dec  7 20:48:38 2011
From: djm at mindrot.org (Damien Miller)
Date: Wed, 7 Dec 2011 20:48:38 +1100 (EST)
Subject: Server moved
In-Reply-To: <20111205234250.GH5573@linux124.nas.nasa.gov>
References: <alpine.BSO.2.00.1111281023090.25728@natsu.mindrot.org>
 <20111205234250.GH5573@linux124.nas.nasa.gov>
Message-ID: <alpine.BSO.2.00.1112071635540.15772@natsu.mindrot.org>

oops, missing crontab - fixed

On Mon, 5 Dec 2011, Iain Morgan wrote:

> On Sun, Nov 27, 2011 at 17:23:58 -0600, Damien Miller wrote:
> > Hi,
> > 
> > The server move was completed over the weekend. Please let me know if
> > anything is broken.
> > 
> > -d
> 
> Hi Damien,
> 
> I just noticed that the last snapshot at
> http://www.mindrot.org/openssh_snap is from the 21st. I suspect that
> this broke with the server move.
> 
> -- 
> Iain Morgan
> 

From alan.r.olsen at intel.com  Thu Dec  8 11:54:45 2011
From: alan.r.olsen at intel.com (Olsen, Alan R)
Date: Thu, 8 Dec 2011 00:54:45 +0000
Subject: Converting SSH2 keys for use in OpenSSH
Message-ID: <4B2793BF110AAB47AB0EE7B90897038525801455@ORSMSX102.amr.corp.intel.com>

I have a couple of keys generated using the F-Secure SSH2 client. I have converted those keys using "ssh-keygen -i -f samplekey.txt >> ~/.ssh/authorized_keys".  When I try and log into the OpenSSH server using those keys, OpenSSH rejects using those keys.

I am under the assumption that this is supposed to work. If I connect using a password, there is no problem. It just does not want to use SSH2 keys.

Is this fixed in a later version? I am seeing this problem on multiple Linux servers and commercial versions of SSH2.

The OpenSSH version is OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011

Here is the log information from the session.

C:\Users\arolsen> "\Program Files (x86)\F-Secure\Ssh\ssh2.exe" -d 4 -a -l alan myserver.intel.com
debug: Ssh2: User config file not found, using defaults. (Looked for 'C:/Users/a
rolsen/AppData/Roaming/F-Secure SSH/ssh2_config')
debug: Ssh2: remote host = "myserver.intel.com"
debug: SshCertEdb: EDB: Adding database: ssh.http
debug: SshCertEdb: EDB: Removing database: ssh.ldap
debug: SshCertEdb: EDB: Adding database: ssh.ldap
debug: Connecting to myserver.intel.com, port 22... (SOCKS not used)
debug: Ssh2: Entering event loop.
debug: Ssh2Client: Creating transport protocol.
debug: Ssh2Transport: Setting new keys and algorithms
debug: Ssh2Transport: Allocating cipher: name: none, key_len: 16.
debug: Ssh2Transport: Setting new keys and algorithms
debug: Ssh2Transport: Allocating cipher: name: none, key_len: 16.
debug: SshAuthMethodClient: Added "keyboard-interactive" to usable methods.
debug: SshAuthMethodClient: Added "publickey" to usable methods.
debug: SshAuthMethodClient: Added "password" to usable methods.
debug: Ssh2Client: Creating userauth protocol.
debug: client supports 3 auth methods: 'keyboard-interactive,publickey,password'

debug: Ssh2Common: local ip = 10.xx.xx.93, local port = 55264
debug: Ssh2Common: remote ip = 10.xx.xx.86, remote port = 22
debug: Ssh2Common: Creating connection protocol.
debug: SshConnection: Wrapping...
debug: SshTcp: Destroying ConnectContext...
debug: Remote version: SSH-2.0-OpenSSH_5.5
debug: OpenSSH: Major: 5 Minor: 5 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses incorrectly.
debug: Ssh2Transport: My version: SSH-1.99-3.2.3 F-Secure SSH Windows Client
debug: Ssh2Transport: local kexinit: first_packet_follows = FALSE
debug: Ssh2Transport: Processing received SSH_MSG_KEXINIT.
debug: Ssh2Transport: Computing algorithms from key exchange.
debug: Ssh2Transport: client: kex = diffie-hellman-group1-sha1, hk_alg = ssh-dss
,ssh-rsa,x509v3-sign-dss,x509v3-sign-rsa
debug: Ssh2Transport: server: kex = diffie-hellman-group-exchange-sha256,diffie-
hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sh
a1, hk_alg = ssh-rsa,ssh-dss
debug: Ssh2Transport: lang s to c: `', lang c to s: `'
debug: Ssh2Transport: first_kex_packet_follows: FALSE
debug: Ssh2Transport: c_to_s: cipher 3des-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport: s_to_c: cipher 3des-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport: Chosen host key algorithm: ssh-dss, Chosen kex algorithm:
diffie-hellman-group1-sha1, Guessed wrong
debug: Ssh2Transport: Guessed host key algorithm: ssh-dss, Guessed kex algorithm
: diffie-hellman-group1-sha1
debug: Ssh2Transport: Constructing the first key exchange packet.
debug: SshProtoTrKex: Making first key exchange packet.
debug: Ssh2Client: Got key of type ssh-dss
debug: Remote host key found from database.
debug: Ssh2Transport: Setting new keys and algorithms
debug: Ssh2Transport: Allocating cipher: name: 3des-cbc, key_len: 24.
debug: Ssh2Transport: Sending service request for "ssh-userauth".
debug: Ssh2Transport: Receiving SSH_MSG_NEWKEYS.
debug: Ssh2Transport: Setting new keys and algorithms
debug: Ssh2Transport: Allocating cipher: name: 3des-cbc, key_len: 24.
debug: Ssh2Transport: Waiting for a service accept packet.
debug: Ssh2Transport: Waiting for a service accept packet.
debug: Ssh2Transport: Received SSH_MSG_SERVICE_ACCEPT with service name "ssh-use
rauth".
debug: Ssh2Transport: Sending startup packet to application layer.
debug: Ssh2Transport: Sending algorithms to application layer.
debug: Ssh2Common: Received SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common: Received SSH_CROSS_ALGORITHMS packet from connection protocol
.
debug: server offers auth methods 'publickey,gssapi-keyex,gssapi-with-mic,passwo
rd'.
debug: Ssh2AuthPubKeyClient: Starting pubkey auth...
debug: Ssh2AuthPubKeyClient: ssh_client_auth_pubkey_agent_open_complete agent=0x
0
debug: Ssh2AuthPubKeyClient: Agent is not running.
debug: Ssh2AuthPubKeyClient: Got 0 keys from the agent.
debug: Ssh2AuthPubKeyClient: Waiting for external keys. 0 seconds gone.
debug: Ssh2AuthPubKeyClient: Waiting for external keys. 0 seconds gone.
debug: SshUnixUserFiles: Found 2 keys from C:\Users\arolsen\AppData\Roaming\F-Se
cure SSH\userkeys
debug: SshUnixUserFiles: Found 0 certificates from C:\Users\arolsen\AppData\Roam
ing\F-Secure SSH\UserCertificates
debug: Ssh2AuthPubKeyClient: adding keyfile "C:\Users\arolsen\AppData\Roaming\F-
Secure SSH\userkeys\TestKey2dsa3k" to candidates
debug: Ssh2AuthPubKeyClient: adding keyfile "C:\Users\arolsen\AppData\Roaming\F-
Secure SSH\userkeys\TestKeyRSA2k" to candidates
debug: Ssh2AuthPubKeyClient: Trying 2 key candidates.
debug: server offers auth methods 'publickey,gssapi-keyex,gssapi-with-mic,passwo
rd'.
debug: server offers auth methods 'publickey,gssapi-keyex,gssapi-with-mic,passwo
rd'.
debug: Ssh2AuthPubKeyClient: All keys declined by server, disabling method.
debug: Ssh2AuthClient: Method 'publickey' disabled.
debug: server offers auth methods 'publickey,gssapi-keyex,gssapi-with-mic,passwo
rd'.
debug: Ssh2AuthPasswdClient: Starting password auth...
alan's password: ^C
C:\Users\arolsen>


From peter at stuge.se  Thu Dec  8 14:46:08 2011
From: peter at stuge.se (Peter Stuge)
Date: Thu, 8 Dec 2011 04:46:08 +0100
Subject: Converting SSH2 keys for use in OpenSSH
In-Reply-To: <4B2793BF110AAB47AB0EE7B90897038525801455@ORSMSX102.amr.corp.intel.com>
References: <4B2793BF110AAB47AB0EE7B90897038525801455@ORSMSX102.amr.corp.intel.com>
Message-ID: <20111208034608.22761.qmail@stuge.se>

Olsen, Alan R wrote:
> debug: Ssh2AuthPubKeyClient: All keys declined by server, disabling method.

This is all that the client can know. Please run sshd -ddd on server.


//Peter

From mike at pair.com  Sat Dec 10 06:53:29 2011
From: mike at pair.com (Mike Kelly)
Date: Fri, 09 Dec 2011 14:53:29 -0500
Subject: Proposal for SFTP extension to include user name and group name in
 file attributes
Message-ID: <4EE26739.4040906@pair.com>

Hello,

I've gathered from searching Bugzilla[1][2] that a patch to update
OpenSSH's SFTP implementation to support version 4 or above of the
protocol is unlikely to be accepted.

However, I find myself wishing for the name-based owner and group
handling specified in version 4 of the spec[3]. As a possible
compromise, if I submitted a patch to add an OpenSSH-specific extension
to return the user name & group name, how likely is it to be accepted?
This would use the extended_type:extended_data mechanism[4] present in
version 3.

This functionality could be useful to clients such as sshfs[5], allowing
file systems to be mounted from other servers with different uid/gid
mappings.

 [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1953#c1
 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=1632#c10
 [3] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-04#section-5.4
 [4] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-5
 [5] http://fuse.sourceforge.net/sshfs.html

-- 
Mike Kelly

From imorgan at nas.nasa.gov  Sat Dec 10 07:20:27 2011
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 9 Dec 2011 12:20:27 -0800
Subject: Server moved
In-Reply-To: <alpine.BSO.2.00.1112071635540.15772@natsu.mindrot.org>
References: <alpine.BSO.2.00.1111281023090.25728@natsu.mindrot.org>
 <20111205234250.GH5573@linux124.nas.nasa.gov>
 <alpine.BSO.2.00.1112071635540.15772@natsu.mindrot.org>
Message-ID: <20111209202027.GH7311@linux124.nas.nasa.gov>

Hi again,

It's still not working, so there must be more to it than the missing
crontab.

-- 
Iain

On Wed, Dec 07, 2011 at 03:48:38 -0600, Damien Miller wrote:
> oops, missing crontab - fixed
> 
> On Mon, 5 Dec 2011, Iain Morgan wrote:
> 
> > On Sun, Nov 27, 2011 at 17:23:58 -0600, Damien Miller wrote:
> > > Hi,
> > > 
> > > The server move was completed over the weekend. Please let me know if
> > > anything is broken.
> > > 
> > > -d
> > 
> > Hi Damien,
> > 
> > I just noticed that the last snapshot at
> > http://www.mindrot.org/openssh_snap is from the 21st. I suspect that
> > this broke with the server move.
> > 
> > -- 
> > Iain Morgan
> > 

-- 
Iain Morgan

From christophe at garault.org  Sat Dec 10 23:18:42 2011
From: christophe at garault.org (Christophe Garault)
Date: Sat, 10 Dec 2011 13:18:42 +0100
Subject: ssh-keygen -K option
Message-ID: <4EE34E22.5090005@garault.org>

Hi there,

     I'm in the process of generating a moduli file under Linux
with 5.9p1 version which in fact takes quite some time for
the big primes to be tested.

     So I've checked both portable and current source code but am unable to
find the -K option wich is documented in the man page of OpenBSD site.
This option is supposed to add a checkpoint file when screening the
candidates with -T option which would be very helpful in my case.

     Can someone give me a hint as of when this was added and where do I
get some patch for this option ? I've quickly checked this list and the
Changelog but can't figure when this option was added.

Thanks in advance.

Christophe Garault


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5363 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111210/2612f4ae/attachment.bin>

From peter at stuge.se  Sun Dec 11 00:37:59 2011
From: peter at stuge.se (Peter Stuge)
Date: Sat, 10 Dec 2011 14:37:59 +0100
Subject: ssh-keygen -K option
In-Reply-To: <4EE34E22.5090005@garault.org>
References: <4EE34E22.5090005@garault.org>
Message-ID: <20111210133759.26766.qmail@stuge.se>

Christophe Garault wrote:
>     So I've checked both portable and current source code but am unable to
> find the -K option wich is documented in the man page of OpenBSD site.
> This option is supposed to add a checkpoint file when screening the
> candidates with -T option which would be very helpful in my case.
>
>     Can someone give me a hint as of when this was added and where do I
> get some patch for this option ? I've quickly checked this list and the
> Changelog but can't figure when this option was added.

Maybe it was added in the OpenBSD OpenSSH code and has not reached
-portable yet. I'm sure you porting it over would be very welcome.

You could verify this by looking up when it was introduced in OpenBSD.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111210/437c4a29/attachment.bin>

From keisial at gmail.com  Sun Dec 11 01:31:33 2011
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 10 Dec 2011 15:31:33 +0100
Subject: ssh-keygen -K option
In-Reply-To: <4EE34E22.5090005@garault.org>
References: <4EE34E22.5090005@garault.org>
Message-ID: <4EE36D45.9080606@gmail.com>

On 10/12/11 13:18, Christophe Garault wrote:
> Hi there,
>
>     I'm in the process of generating a moduli file under Linux
> with 5.9p1 version which in fact takes quite some time for
> the big primes to be tested.
>
>     So I've checked both portable and current source code but am
> unable to
> find the -K option wich is documented in the man page of OpenBSD site.
> This option is supposed to add a checkpoint file when screening the
> candidates with -T option which would be very helpful in my case.
>
>     Can someone give me a hint as of when this was added and where do I
> get some patch for this option ? I've quickly checked this list and the
> Changelog but can't figure when this option was added.
>
> Thanks in advance.
>
> Christophe Garault

It was added in October, so it's not yet on any release.
http://anoncvs.mindrot.org/index.cgi/openssh/ssh-keygen.1?r1=1.103&r2=1.104
http://anoncvs.mindrot.org/index.cgi/openssh/ssh-keygen.c?r1=1.228&r2=1.229

You can try build ssh-keygen from a nightly snapshot:
http://www.mindrot.org/openssh_snap/


From christophe at garault.org  Sun Dec 11 02:50:56 2011
From: christophe at garault.org (Christophe Garault)
Date: Sat, 10 Dec 2011 16:50:56 +0100
Subject: ssh-keygen -K option
In-Reply-To: <20111210133759.26766.qmail@stuge.se>
References: <4EE34E22.5090005@garault.org>
 <20111210133759.26766.qmail@stuge.se>
Message-ID: <4EE37FE0.1050208@garault.org>

Le 10/12/2011 14:37, Peter Stuge a ?crit :
> Maybe it was added in the OpenBSD OpenSSH code and has not reached
> -portable yet. I'm sure you porting it over would be very welcome.
>
> You could verify this by looking up when it was introduced in OpenBSD.
Peter,

I must admit that I was naive enough to not imagine the OpenBSD version 
could be different.

Here it is:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/moduli.c.diff?r1=1.22;r2=1.23 


Thanks.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5363 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111210/4c36183a/attachment-0001.bin>

From christophe at garault.org  Sun Dec 11 02:52:49 2011
From: christophe at garault.org (Christophe Garault)
Date: Sat, 10 Dec 2011 16:52:49 +0100
Subject: ssh-keygen -K option
In-Reply-To: <4EE36D45.9080606@gmail.com>
References: <4EE34E22.5090005@garault.org> <4EE36D45.9080606@gmail.com>
Message-ID: <4EE38051.6080602@garault.org>

Le 10/12/2011 15:31, ?ngel Gonz?lez a ?crit :
>
> You can try build ssh-keygen from a nightly snapshot:
> http://www.mindrot.org/openssh_snap/
>
>    
Exactly what I need, thanks a lot ?ngel.

Nice w-e to yall.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5363 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111210/1558df4c/attachment.bin>

From djm at mindrot.org  Sun Dec 11 13:35:23 2011
From: djm at mindrot.org (Damien Miller)
Date: Sun, 11 Dec 2011 13:35:23 +1100 (EST)
Subject: Server moved
In-Reply-To: <20111209202027.GH7311@linux124.nas.nasa.gov>
References: <alpine.BSO.2.00.1111281023090.25728@natsu.mindrot.org>
 <20111205234250.GH5573@linux124.nas.nasa.gov>
 <alpine.BSO.2.00.1112071635540.15772@natsu.mindrot.org>
 <20111209202027.GH7311@linux124.nas.nasa.gov>
Message-ID: <alpine.BSO.2.00.1112111335100.29299@natsu.mindrot.org>

On Fri, 9 Dec 2011, Iain Morgan wrote:

> Hi again,
> 
> It's still not working, so there must be more to it than the missing
> crontab.

oops, fixed for real now.

From tony.kay at gmail.com  Wed Dec 14 09:52:38 2011
From: tony.kay at gmail.com (Tony Kay)
Date: Tue, 13 Dec 2011 14:52:38 -0800
Subject: ssh-agent and IdentityFile
Message-ID: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>

I've noticed that the ssh-agent applies any keys it already has
passwords for (via ssh-add) first, overriding the ssh config files for
preferred identity file from .ssh/config and -i. This seems a
documented behavior.

However, this causes problems with some tool chains that use the
authorized_keys command directive to change behavior based on which
key is used.

In my case, I use gitolite for git repositories, and we have a number
of developers, each with different permissions. As the admin, I have
more than one SSH identity that gives me different permissions on the
server (again, through a command directive on authorized_keys on the
server).

So, my .ssh/config uses two different Host configs, so I can use the
alias hostname to get to the different access permissions:

Host=hostA
Hostname=repos.example.com
IdentityFile=usera

Host=hostAAdmin
Hostname=repos.example.com
IdentityFile=userb

Of course, these key files are password protected.

Once ssh-agent has the usera or userb key installed, it ignores the
config...meaning I have to do a lot of shuffling with ssh-add...and
I've lost the benefit of using ssh-agent at all...worse, now I'm
typing ssh-add -D, followed by ssh-add identity, followed by the
password again! I just end up killing ssh-agent and typing
passwords....unless I'm on OSX, which auto-starts ssh-agent every time
I use ssh.

This seems incorrect, since I would not have configured IdentityFile
if it didn't matter to me.

I would consider this a bug, though I know it is a documented
"feature"...which is why I'm writing here.

Please enlighten me.

Tony

From dkg at fifthhorseman.net  Thu Dec 15 03:40:32 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Dec 2011 11:40:32 -0500
Subject: ssh-agent and IdentityFile
In-Reply-To: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
References: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
Message-ID: <4EE8D180.4060908@fifthhorseman.net>

On 12/13/2011 05:52 PM, Tony Kay wrote:
> Host=hostAAdmin
> Hostname=repos.example.com
> IdentityFile=userb
> 
> Of course, these key files are password protected.

Have you tried setting IdentityFile to userb.pub instead of userb and
loading userb into the agent?  The .pub files (containing only the
public key) will not be password-protected.  I was told by a colleague
that specifying the .pub form let her ssh client prioritize which of the
several keys she had loaded into her agent she would offer to the server
first.

I haven't had a chance to test it myself yet, nor do i remember what
version of OpenSSH my colleague was using.

If it works for you (or doesn't), please report back!

hth,

	--dkg

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

From keisial at gmail.com  Thu Dec 15 08:54:30 2011
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 14 Dec 2011 22:54:30 +0100
Subject: ssh-agent and IdentityFile
In-Reply-To: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
References: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
Message-ID: <4EE91B16.3050809@gmail.com>

On 13/12/11 23:52, Tony Kay wrote:
> Once ssh-agent has the usera or userb key installed, it ignores the
> config...meaning I have to do a lot of shuffling with ssh-add...and
> I've lost the benefit of using ssh-agent at all...worse, now I'm
> typing ssh-add -D, followed by ssh-add identity, followed by the
> password again! I just end up killing ssh-agent and typing
> passwords....unless I'm on OSX, which auto-starts ssh-agent every time
> I use ssh.
You could do
SSH_AUTH_SOCK= ssh hostAAdmin

You would be effectively disabling the ssh agent (by emptying the
SSH_AUTH_SOCK env var to the child ssh process),
which means that you will need to enter the password manually. Still,
seems better than the current approach.

A more advanced approach would be to have two ssh agents on different
sockets, and switch among them, playing or
perhaps with wrappers, or having SSH_AUTH_SOCK point to a symlink that
you repoint to one or another as you change
hats.

I know it doesn't solve the underlying problem (yes, it looks like a
bug), but hopefully it can make your life a bit easier.


From phil.pennock at globnix.org  Thu Dec 15 11:21:42 2011
From: phil.pennock at globnix.org (Phil Pennock)
Date: Wed, 14 Dec 2011 19:21:42 -0500
Subject: ssh-agent and IdentityFile
In-Reply-To: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
References: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
Message-ID: <20111215002142.GA5967@redoubt.spodhuis.org>

On 2011-12-13 at 14:52 -0800, Tony Kay wrote:
> I've noticed that the ssh-agent applies any keys it already has
> passwords for (via ssh-add) first, overriding the ssh config files for
> preferred identity file from .ssh/config and -i. This seems a
> documented behavior.

ssh_config(5):
     IdentitiesOnly
             Specifies that ssh(1) should only use the authentication identity
             files configured in the ssh_config files, even if ssh-agent(1)
             offers more identities.  The argument to this keyword must be
             ``yes'' or ``no''.  This option is intended for situations where
             ssh-agent offers many different identities.  The default is
             ``no''.


From mjflick at gnu.org  Thu Dec 15 11:23:55 2011
From: mjflick at gnu.org (Michael J. Flickinger)
Date: Wed, 14 Dec 2011 19:23:55 -0500
Subject: Retrieving authorized_keys via remote script
Message-ID: <4EE93E1B.2020408@gnu.org>

Here's a simple patch which retrieves authorized_keys via exec'ing a 
program, rather than reading a flat file.

I added a simple option, AuthorizedKeysExec, to sshd_config which simply 
executes the respective file, passing the username as argv[1].
Keys are returned via stdout.

Notes:

If AuthorizedKeysExec is set and an authorized_keys file exists, 
checking the existing authorized_keys file takes precedence.

I believe this to be a more simplistic and trivial patch to openssh 
opposed to the pre-existing patches, such as the popular LDAP patch 
(http://code.google.com/p/openssh-lpk/).

Best,

--
Michael J. Flickinger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 5655 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111214/437dbeba/attachment.bin>

From tony.kay at gmail.com  Thu Dec 15 12:42:29 2011
From: tony.kay at gmail.com (Tony Kay)
Date: Wed, 14 Dec 2011 17:42:29 -0800
Subject: ssh-agent and IdentityFile
In-Reply-To: <20111215002142.GA5967@redoubt.spodhuis.org>
References: <CAOQqBoAy=ANBFf5LeTnnsstqr=E=fDgyeA_+bJmHu3ynpW5G7w@mail.gmail.com>
 <20111215002142.GA5967@redoubt.spodhuis.org>
Message-ID: <CAOQqBoD7ye5Yx9YTq0i1qE-yrYdwgDGPWvQpOKEHigPEoKp6ew@mail.gmail.com>

Phil,

Perfect. I don't know how I missed that.

Thanks!

Tony

P.s. Thanks to the other responders as well. The env variable trick
with multiple agents was the next best thing.

On Wed, Dec 14, 2011 at 4:21 PM, Phil Pennock <phil.pennock at globnix.org> wrote:
> On 2011-12-13 at 14:52 -0800, Tony Kay wrote:
>> I've noticed that the ssh-agent applies any keys it already has
>> passwords for (via ssh-add) first, overriding the ssh config files for
>> preferred identity file from .ssh/config and -i. This seems a
>> documented behavior.
>
> ssh_config(5):
> ? ? IdentitiesOnly
> ? ? ? ? ? ? Specifies that ssh(1) should only use the authentication identity
> ? ? ? ? ? ? files configured in the ssh_config files, even if ssh-agent(1)
> ? ? ? ? ? ? offers more identities. ?The argument to this keyword must be
> ? ? ? ? ? ? ``yes'' or ``no''. ?This option is intended for situations where
> ? ? ? ? ? ? ssh-agent offers many different identities. ?The default is
> ? ? ? ? ? ? ``no''.
>

From jrollins at finestructure.net  Thu Dec 15 13:19:18 2011
From: jrollins at finestructure.net (Jameson Graef Rollins)
Date: Wed, 14 Dec 2011 18:19:18 -0800
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <4EE93E1B.2020408@gnu.org>
References: <4EE93E1B.2020408@gnu.org>
Message-ID: <874nx21srd.fsf@servo.finestructure.net>

On Wed, 14 Dec 2011 19:23:55 -0500, "Michael J. Flickinger" <mjflick at gnu.org> wrote:
> Here's a simple patch which retrieves authorized_keys via exec'ing a 
> program, rather than reading a flat file.

Hi, Michael.  There are actually already some outstanding patches to
support this behavior:

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

The approach above is similar to the one you are suggesting.  Hopefully
the existing patches would also work for you.  Feel free to add to the
discussion in the above bugzilla report.

jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111214/c7138d81/attachment.bin>

From mjflick at gnu.org  Thu Dec 15 13:33:46 2011
From: mjflick at gnu.org (Michael J. Flickinger)
Date: Wed, 14 Dec 2011 21:33:46 -0500
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <874nx21srd.fsf@servo.finestructure.net>
References: <4EE93E1B.2020408@gnu.org> <874nx21srd.fsf@servo.finestructure.net>
Message-ID: <4EE95C8A.7090307@gnu.org>

On 12/14/2011 09:19 PM, Jameson Graef Rollins wrote:
> On Wed, 14 Dec 2011 19:23:55 -0500, "Michael J. Flickinger"<mjflick at gnu.org>  wrote:
>> Here's a simple patch which retrieves authorized_keys via exec'ing a
>> program, rather than reading a flat file.
>
> Hi, Michael.  There are actually already some outstanding patches to
> support this behavior:
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=1663
>
> The approach above is similar to the one you are suggesting.  Hopefully
> the existing patches would also work for you.  Feel free to add to the
> discussion in the above bugzilla report.
>
> jamie.

Is there any reason why that patch is not included?

--
Michael

From djm at mindrot.org  Mon Dec 19 10:54:28 2011
From: djm at mindrot.org (Damien Miller)
Date: Mon, 19 Dec 2011 10:54:28 +1100 (EST)
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <4EE95C8A.7090307@gnu.org>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
Message-ID: <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>

On Wed, 14 Dec 2011, Michael J. Flickinger wrote:

> On 12/14/2011 09:19 PM, Jameson Graef Rollins wrote:
> > On Wed, 14 Dec 2011 19:23:55 -0500, "Michael J. Flickinger"<mjflick at gnu.org>
> > wrote:
> > > Here's a simple patch which retrieves authorized_keys via exec'ing a
> > > program, rather than reading a flat file.
> > 
> > Hi, Michael.  There are actually already some outstanding patches to
> > support this behavior:
> > 
> > https://bugzilla.mindrot.org/show_bug.cgi?id=1663
> > 
> > The approach above is similar to the one you are suggesting.  Hopefully
> > the existing patches would also work for you.  Feel free to add to the
> > discussion in the above bugzilla report.
> > 
> > jamie.
> 
> Is there any reason why that patch is not included?

I've been slacking (well, busy with other stuff). I hope to look at them
in the quiet of a new year.

-d

From mjflick at gnu.org  Tue Dec 20 07:17:24 2011
From: mjflick at gnu.org (Michael J. Flickinger)
Date: Mon, 19 Dec 2011 15:17:24 -0500
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
 <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
Message-ID: <4EEF9BD4.4030801@gnu.org>

On 12/18/2011 06:54 PM, Damien Miller wrote:
>> Is there any reason why that patch is not included?
>
> I've been slacking (well, busy with other stuff). I hope to look at them
> in the quiet of a new year.
>
> -d

That would be fantastic.

I'm sure plenty of people would be incredibly grateful if that patch 
could be incorporated, since it provides a clean and safe way to extend 
the authorized_keys functionality.


From peter at stuge.se  Tue Dec 20 07:49:47 2011
From: peter at stuge.se (Peter Stuge)
Date: Mon, 19 Dec 2011 21:49:47 +0100
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <4EEF9BD4.4030801@gnu.org>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
 <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
 <4EEF9BD4.4030801@gnu.org>
Message-ID: <20111219204948.11032.qmail@stuge.se>

Michael J. Flickinger wrote:
> a clean and safe way to extend the authorized_keys functionality.

How safe it is depends on what you execute I guess.


//Peter

From mjflick at gnu.org  Tue Dec 20 08:23:54 2011
From: mjflick at gnu.org (Michael J. Flickinger)
Date: Mon, 19 Dec 2011 16:23:54 -0500
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <20111219204948.11032.qmail@stuge.se>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
 <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
 <4EEF9BD4.4030801@gnu.org> <20111219204948.11032.qmail@stuge.se>
Message-ID: <4EEFAB6A.7070202@gnu.org>

On 12/19/2011 03:49 PM, Peter Stuge wrote:
> Michael J. Flickinger wrote:
>> a clean and safe way to extend the authorized_keys functionality.
>
> How safe it is depends on what you execute I guess.

You cannot really baby-sit the user though, they can already do unsafe 
things...


From peter at stuge.se  Tue Dec 20 17:09:14 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 20 Dec 2011 07:09:14 +0100
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <4EEFAB6A.7070202@gnu.org>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
 <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
 <4EEF9BD4.4030801@gnu.org> <20111219204948.11032.qmail@stuge.se>
 <4EEFAB6A.7070202@gnu.org>
Message-ID: <20111220060914.19007.qmail@stuge.se>

Michael J. Flickinger wrote:
>>> a clean and safe way to extend the authorized_keys functionality.
>>
>> How safe it is depends on what you execute I guess.
>
> You cannot really baby-sit the user though, they can already do
> unsafe things...

It's not about the user, but about root who runs sshd, and suddenly
requires even more clue in order to run a tight ship.

I completely understand being conservative with adding hooks and
"plugins" in sshd.


//Peter

From mjflick at gnu.org  Wed Dec 21 01:01:48 2011
From: mjflick at gnu.org (Michael J. Flickinger)
Date: Tue, 20 Dec 2011 09:01:48 -0500
Subject: Retrieving authorized_keys via remote script
In-Reply-To: <20111220122138.5669.qmail@stuge.se>
References: <4EE93E1B.2020408@gnu.org>
 <874nx21srd.fsf@servo.finestructure.net> <4EE95C8A.7090307@gnu.org>
 <alpine.BSO.2.00.1112191054020.30101@natsu.mindrot.org>
 <4EEF9BD4.4030801@gnu.org> <20111219204948.11032.qmail@stuge.se>
 <4EEFAB6A.7070202@gnu.org> <20111220060914.19007.qmail@stuge.se>
 <4EF07CEF.4090107@gnu.org> <20111220122138.5669.qmail@stuge.se>
Message-ID: <4EF0954C.4090605@gnu.org>

On 12/20/11 7:21 AM, Peter Stuge wrote:
> Michael J. Flickinger wrote:
>>>>>> a clean and safe way to extend the authorized_keys functionality.
>>>>>
>>>>> How safe it is depends on what you execute I guess.
>>>>
>>>> You cannot really baby-sit the user though, they can already do
>>>> unsafe things...
>>>
>>> It's not about the user, but about root who runs sshd, and suddenly
>>> requires even more clue in order to run a tight ship.
>>>
>>> I completely understand being conservative with adding hooks and
>>> "plugins" in sshd.
>>
>> For what it's worth, the exec is not being run as root in that patch.
>
> This is good! It means that problems will affect users, and not the
> full system, but still there can be problems which will affect users.
>
>
> //Peter

Well, I believe that patch lets you specify a user to run the exec...
I'm not sure what can be done beyond that.

For what it's worth, whoever is running the system could do something 
equally as bad with pam_exec.


From plautrba at redhat.com  Wed Dec 21 01:31:41 2011
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 20 Dec 2011 15:31:41 +0100
Subject: ssh-copy-id -p port option
Message-ID: <4EF09C4D.6030203@redhat.com>

Hi.

I would like to add an option [-p port] to ssh-copy-id.

If this option is given then ssh-copy-id calls ssh with -p port to connect to
non-standard port.

The patch [1] adds this option to ssh-copy-id and documents it in ssh-copy-id(1) man page

[1] http://plautrba.fedorapeople.org/openssh/718674/ssh-copy-id-p-port.patch


Thanks,

Petr



diff --git a/contrib/ssh-copy-id b/contrib/ssh-copy-id
index 9451ace..a824382 100644
--- a/contrib/ssh-copy-id
+++ b/contrib/ssh-copy-id
@@ -6,22 +6,49 @@
  # or one of the other keys in your ssh-agent, for this to work.

  ID_FILE="${HOME}/.ssh/id_rsa.pub"
+COMMAND="ssh"

-if [ "-i" = "$1" ]; then
-  shift
-  # check if we have 2 parameters left, if so the first is the new ID file
-  if [ -n "$2" ]; then
-    if expr "$1" : ".*\.pub" > /dev/null ; then
-      ID_FILE="$1"
-    else
-      ID_FILE="$1.pub"
-    fi
-    shift         # and this should leave $1 as the target name
-  fi
-else
-  if [ x$SSH_AUTH_SOCK != x ] && ssh-add -L >/dev/null 2>&1; then
-    GET_ID="$GET_ID ssh-add -L"
-  fi
+while [ $# -gt 0 ]; do
+  case "$1" in
+    -i)
+      shift
+      # remains last argument or next argument is another option
+      if [ -z "$2" ] || expr "$1" : "^--\?[a-z]*\$" > /dev/null ; then
+        OPT_I="$ID_FILE"
+        continue;
+      fi
+      OPT_I="$1"
+      if expr "$1" : ".*\.pub" > /dev/null ; then
+        ID_FILE="$1"
+      else
+        ID_FILE="$1.pub"
+      fi
+      shift
+      continue
+      ;;
+    -p)
+      shift
+      COMMAND="$COMMAND -p $1"
+      shift
+      continue
+      ;;
+    -h|--help)
+      shift $#
+      break
+      ;;
+    *)
+      break
+      ;;
+  esac
+done
+
+if [ "$#" -ne 1 ]; then
+  echo "Usage: $0 [-i [identity_file]] [-p port] [user@]machine" >&2
+  exit 1
+fi
+
+if [ -z "$OPT_I" ] && [ x$SSH_AUTH_SOCK != x ] && ssh-add -L >/dev/null 2>&1; then
+  GET_ID="$GET_ID ssh-add -L"
  fi

  if [ -z "`eval $GET_ID`" ] && [ -r "${ID_FILE}" ] ; then
@@ -33,18 +60,13 @@ if [ -z "`eval $GET_ID`" ]; then
    exit 1
  fi

-if [ "$#" -lt 1 ] || [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
-  echo "Usage: $0 [-i [identity_file]] [user@]machine" >&2
-  exit 1
-fi
-
  # strip any trailing colon
  host=`echo $1 | sed 's/:$//'`

-{ eval "$GET_ID" ; } | ssh $host "umask 077; test -d ~/.ssh || mkdir ~/.ssh ; cat >> ~/.ssh/authorized_keys" || exit 1
+{ eval "$GET_ID" ; } | $COMMAND $host "umask 077; test -d ~/.ssh || mkdir ~/.ssh ; cat >> ~/.ssh/authorized_keys" || exit 1

  cat <<EOF
-Now try logging into the machine, with "ssh '$host'", and check in:
+Now try logging into the machine, with "$COMMAND '$host'", and check in:

    ~/.ssh/authorized_keys

diff --git a/contrib/ssh-copy-id.1 b/contrib/ssh-copy-id.1
index cb15ab2..ed81a92 100644
--- a/contrib/ssh-copy-id.1
+++ b/contrib/ssh-copy-id.1
@@ -20,7 +20,7 @@ the original English.
  .SH NAME
  ssh-copy-id \- install your public key in a remote machine's authorized_keys
  .SH SYNOPSIS
-.B ssh-copy-id [-i [identity_file]]
+.B ssh-copy-id [-i [identity_file]] [-p port]
  .I "[user@]machine"
  .br
  .SH DESCRIPTION
@@ -51,6 +51,11 @@ file.  Once it has one or more fingerprints (by whatever means) it
  uses ssh to append them to
  .B ~/.ssh/authorized_keys
  on the remote machine (creating the file, and directory, if necessary.)
+.PP
+If the
+.B -p
+option is given then the port is used to log in into a remote machine with
+sshd listening on non-standard port.

  .SH NOTES
  This program does not modify the permissions of any

-- 
Petr Lautrbach, Red Hat, Inc.
http://cz.redhat.com

From michael at stummi.org  Wed Dec 21 02:23:19 2011
From: michael at stummi.org (Michael Stummvoll)
Date: Tue, 20 Dec 2011 16:23:19 +0100
Subject: sshd: Allow more directives in Match-Block
Message-ID: <4EF0A867.5030702@stummi.org>

Hi,

I think, there are some more directives, which could be allowed in the 
Match block in the sshd_config.
For myself, i needed PrintMotd, PrintLastlog and PermitUserEnvironment 
within a Match block, so i wrote a patch to add these, which worked for 
me, but may there are some more options, which would make sense in a 
Match block.
May other users of SSH could need something like this too, so I attached 
the patch looking forward, it goes into the vanilla source

Greetings,
Michael

PS: I am not subscribed, so please CC related discussion to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: servconf.patch
Type: text/x-diff
Size: 1434 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111220/50b1c284/attachment.bin>

From bob at proulx.com  Wed Dec 21 09:52:23 2011
From: bob at proulx.com (Bob Proulx)
Date: Tue, 20 Dec 2011 15:52:23 -0700
Subject: ssh-copy-id -p port option
In-Reply-To: <4EF09C4D.6030203@redhat.com>
References: <4EF09C4D.6030203@redhat.com>
Message-ID: <20111220225223.GB16758@discord.proulx.com>

Petr Lautrbach wrote:
> I would like to add an option [-p port] to ssh-copy-id.
>
> If this option is given then ssh-copy-id calls ssh with -p port to connect to
> non-standard port.

If a non-standard port is needed then typically people configure this
option in their ssh config file.  Do that once and it is done
everywhere.  Is there a reason not to do that for ssh-copy-id too?

This is not a comment upon the patch itself or whether it is useful to
regularize the options and option processing.

Bob

From phil at hands.com  Wed Dec 21 10:12:40 2011
From: phil at hands.com (Philip Hands)
Date: Tue, 20 Dec 2011 23:12:40 +0000
Subject: ssh-copy-id -p port option
In-Reply-To: <4EF09C4D.6030203@redhat.com>
References: <4EF09C4D.6030203@redhat.com>
Message-ID: <87k45q6dnb.fsf@poker.hands.com>

On Tue, 20 Dec 2011 15:31:41 +0100, Petr Lautrbach <plautrba at redhat.com> wrote:
> Hi.

Hi Petr,

Sorry to have wasted your time by not trying hard enough to push my more
recent version of ssh-copy-id more forcefully, but you may like to have
a look at it to see if it does everything you need:

  http://git.hands.com/ssh-copy-id

To everyone else here, is there any particular reason why nothing ever
happened about updating this when I mentioned it just over a year ago?

See:  http://marc.info/?l=openssh-unix-dev&m=129251466902120

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111220/ba949596/attachment-0001.bin>

From jrollins at finestructure.net  Wed Dec 21 10:29:01 2011
From: jrollins at finestructure.net (Jameson Graef Rollins)
Date: Tue, 20 Dec 2011 15:29:01 -0800
Subject: ssh-copy-id -p port option
In-Reply-To: <20111220225223.GB16758@discord.proulx.com>
References: <4EF09C4D.6030203@redhat.com>
 <20111220225223.GB16758@discord.proulx.com>
Message-ID: <87mxamstz6.fsf@servo.finestructure.net>

On Tue, 20 Dec 2011 15:52:23 -0700, Bob Proulx <bob at proulx.com> wrote:
> If a non-standard port is needed then typically people configure this
> option in their ssh config file.  Do that once and it is done
> everywhere.  Is there a reason not to do that for ssh-copy-id too?

I would say that it is not particularly helpful to have to add a stanza
to the config for an operation that probably only needs to be done
once.

jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111220/94cfef24/attachment.bin>

From bob at proulx.com  Wed Dec 21 11:12:00 2011
From: bob at proulx.com (Bob Proulx)
Date: Tue, 20 Dec 2011 17:12:00 -0700
Subject: ssh-copy-id -p port option
In-Reply-To: <87mxamstz6.fsf@servo.finestructure.net>
References: <4EF09C4D.6030203@redhat.com>
 <20111220225223.GB16758@discord.proulx.com>
 <87mxamstz6.fsf@servo.finestructure.net>
Message-ID: <20111221001200.GA10266@hysteria.proulx.com>

Jameson Graef Rollins wrote:
> Bob Proulx wrote:
> > If a non-standard port is needed then typically people configure this
> > option in their ssh config file.  Do that once and it is done
> > everywhere.  Is there a reason not to do that for ssh-copy-id too?
> 
> I would say that it is not particularly helpful to have to add a stanza
> to the config for an operation that probably only needs to be done
> once.

Are you really only ever going to do this once?  If so then why go to
the trouble of installing a key?  Going to the trouble of installing a
key implies to me that this will be a repeat visit.

In a situation where a non-standard port is required I don't think
that always needing to type the port number on the command line is
particularly nice either.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111220/0ecc8efa/attachment.bin>

From v.shalchian at gmail.com  Sat Dec 31 20:40:54 2011
From: v.shalchian at gmail.com (Vahab Shalchian)
Date: Sat, 31 Dec 2011 13:10:54 +0330
Subject: A probable useful feature
Message-ID: <CAA7iwgVeUJJLU-R-C_8xqNbFi=NNi2ux0R5t3GU81ztViD9icw@mail.gmail.com>

Hi,

As I mentioned in the following post :

http://www.linuxquestions.org/questions/linux-security-4/exclude-a-from-being-logged-in-var-log-wtmp-920865/

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

Is it possible to include this feature in the next releases of SSH.

Many thanks.
Vahab Shalchian