From dwmw2 at infradead.org Mon Jul 2 22:39:47 2012 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 02 Jul 2012 13:39:47 +0100 Subject: warning from configuring openssh-6.0p1 In-Reply-To: <001101cd2e29$a92fee80$fb8fcb80$@cainetworks.com> References: <001101cd2e29$a92fee80$fb8fcb80$@cainetworks.com> Message-ID: <1341232787.26748.389.camel@shinybook.infradead.org> On Wed, 2012-05-09 at 14:21 -0700, Support Team wrote: > In file included from conftest.c:108: > /usr/include/linux/filter.h:21: error: parse error before "__u16" > /usr/include/linux/filter.h:23: error: parse error before "jf" > /usr/include/linux/filter.h:24: error: parse error before "k" Sounds like your isn't including . Including that manually, first, may suffice to fix it if you really need BPF functionality. If you're just commenting on the *warning*, then what do you expect? This system has been EOL for about 8 years already. I don't know when that missing #include was added. It was already there by the time of the first commit in the kernel repo, over 7 years ago. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6171 bytes Desc: not available URL: From dtucker at zip.com.au Tue Jul 3 01:23:48 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 3 Jul 2012 01:23:48 +1000 Subject: rlimit sandbox on cygwin Message-ID: <20120702152348.GA3293@gate.dtucker.net> Hi all. I have an old windows VM with an oldish cygwin that I use for the regression tests. Investigating one of the test failures, I see that it's for UsePrivilegeSeparation=sandbox, and it seems to be because setrlimit(RLIMIT_FSIZE, ...) is not supported. IMO, this isn't a big loss, since the most useful thing in the rlimit "sandbox" is the descriptor limits. Can anyone see a reason not to just omit RLIMIT_FSIZE on cygwin? It's a no-op unless you've explicitly set "UsePrivilegeSeparation sandbox" in sshd_config. Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.492 diff -u -p -r1.492 configure.ac --- configure.ac 19 May 2012 05:24:37 -0000 1.492 +++ configure.ac 2 Jul 2012 15:17:56 -0000 @@ -511,6 +511,7 @@ case "$host" in file descriptor passing]) AC_DEFINE([SSH_IOBUFSZ], [65535], [Windows is sensitive to read buffer size]) AC_DEFINE([FILESYSTEM_NO_BACKSLASH], [1], [File names may not contain backslash characters]) + AC_DEFINE([SANDBOX_SKIP_RLIMIT_FSIZE], [1], [Do not try rlimit FSIZE]) ;; *-*-dgux*) AC_DEFINE([IP_TOS_IS_BROKEN], [1], Index: sandbox-rlimit.c =================================================================== RCS file: /var/cvs/openssh/sandbox-rlimit.c,v retrieving revision 1.2 diff -u -p -r1.2 sandbox-rlimit.c --- sandbox-rlimit.c 23 Jun 2011 09:45:51 -0000 1.2 +++ sandbox-rlimit.c 2 Jul 2012 15:17:56 -0000 @@ -64,9 +64,11 @@ ssh_sandbox_child(struct ssh_sandbox *bo rl_zero.rlim_cur = rl_zero.rlim_max = 0; +#ifndef SANDBOX_SKIP_RLIMIT_FSIZE if (setrlimit(RLIMIT_FSIZE, &rl_zero) == -1) fatal("%s: setrlimit(RLIMIT_FSIZE, { 0, 0 }): %s", __func__, strerror(errno)); +#endif if (setrlimit(RLIMIT_NOFILE, &rl_zero) == -1) fatal("%s: setrlimit(RLIMIT_NOFILE, { 0, 0 }): %s", __func__, strerror(errno)); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jul 3 11:31:10 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 3 Jul 2012 11:31:10 +1000 Subject: warning from configuring openssh-6.0p1 In-Reply-To: <1341232787.26748.389.camel@shinybook.infradead.org> References: <001101cd2e29$a92fee80$fb8fcb80$@cainetworks.com> <1341232787.26748.389.camel@shinybook.infradead.org> Message-ID: <20120703013110.GA24106@gate.dtucker.net> On Mon, Jul 02, 2012 at 01:39:47PM +0100, David Woodhouse wrote: > On Wed, 2012-05-09 at 14:21 -0700, Support Team wrote: > > In file included from conftest.c:108: > > /usr/include/linux/filter.h:21: error: parse error before "__u16" > > /usr/include/linux/filter.h:23: error: parse error before "jf" > > /usr/include/linux/filter.h:24: error: parse error before "k" > > Sounds like your isn't including . > Including that manually, first, may suffice to fix it if you really need > BPF functionality. If you're just commenting on the *warning*, then what > do you expect? This system has been EOL for about 8 years already. Well, configure *does* emit a warning asking folks to report the warning in this case. It's the default behaviour on the part of autoconf (personally, I don't think the present-but-not-compilable behaviour is all that helpful, but that's what autoconf does). Anyway, the BPF functionality is only used for the SECCOMP_MODE_FILTER sandbox, and since that's only in the very newest kernels the warning is harmless on older systems. As a general comment on support for older systems: my policy (such as it is) is that as long as someone is willing to do the work, and it does not compromise either security or maintainability then I'm happy to support older and/or esoteric platforms. > I don't know when that missing #include was added. It was already there > by the time of the first commit in the kernel repo, over 7 years ago. Could the OP please try the patch below? You'll need to run "autoreconf" to rebuild configure, or you can use the prebuilt one against 6.0p1 I put up here: http://www.dtucker.net/~dtucker/tmp/linux-filter/configure.gz Thanks. Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.492 diff -u -p -r1.492 configure.ac --- configure.ac 19 May 2012 05:24:37 -0000 1.492 +++ configure.ac 3 Jul 2012 01:10:21 -0000 @@ -686,7 +686,8 @@ main() { if (NSVersionOfRunTimeLibrary(" AC_DEFINE([SSH_TUN_PREPEND_AF], [1], [Prepend the address family to IP tunnel traffic]) fi - AC_CHECK_HEADERS([linux/seccomp.h linux/filter.h linux/audit.h]) + AC_CHECK_HEADERS([linux/seccomp.h linux/filter.h linux/audit.h], [], + [], [#include ]) AC_CHECK_FUNCS([prctl]) have_seccomp_audit_arch=1 case "$host" in -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jul 3 22:45:20 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 3 Jul 2012 22:45:20 +1000 Subject: rlimit sandbox on cygwin In-Reply-To: <20120702152348.GA3293@gate.dtucker.net> References: <20120702152348.GA3293@gate.dtucker.net> Message-ID: <20120703124520.GA30700@gate.dtucker.net> On Tue, Jul 03, 2012 at 01:23:48AM +1000, Darren Tucker wrote: > Hi all. > > I have an old windows VM with an oldish cygwin that I use for the > regression tests. Investigating one of the test failures, I see that > it's for UsePrivilegeSeparation=sandbox, and it seems to be because > setrlimit(RLIMIT_FSIZE, ...) is not supported. > > IMO, this isn't a big loss, since the most useful thing in the rlimit > "sandbox" is the descriptor limits. Can anyone see a reason not to just > omit RLIMIT_FSIZE on cygwin? It's a no-op unless you've explicitly set > "UsePrivilegeSeparation sandbox" in sshd_config. On second thought, it might be better to explicitly test RLIMIT_FSIZE in configure, like so. Index: configure.ac =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v retrieving revision 1.493 diff -u -p -r1.493 configure.ac --- configure.ac 3 Jul 2012 04:31:18 -0000 1.493 +++ configure.ac 3 Jul 2012 12:30:30 -0000 @@ -2615,6 +2615,25 @@ AC_RUN_IFELSE( [AC_MSG_WARN([cross compiling: assuming yes])] ) +AC_MSG_CHECKING([if setrlimit RLIMIT_FSIZE works]) +AC_RUN_IFELSE( + [AC_LANG_PROGRAM([[ +#include +#include +#include + ]],[[ + struct rlimit rl_zero; + + rl_zero.rlim_cur = rl_zero.rlim_max = 0; + exit(setrlimit(RLIMIT_FSIZE, &rl_zero) != 0); + ]])], + [AC_MSG_RESULT([yes])], + [AC_MSG_RESULT([no]) + AC_DEFINE(SANDBOX_SKIP_RLIMIT_FSIZE, 1, + [setrlimit RLIMIT_FSIZE works])], + [AC_MSG_WARN([cross compiling: assuming yes])] +) + if test "x$sandbox_arg" = "xsystrace" || \ ( test -z "$sandbox_arg" && test "x$have_systr_policy_kill" = "x1" ) ; then test "x$have_systr_policy_kill" != "x1" && \ Index: sandbox-rlimit.c =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/sandbox-rlimit.c,v retrieving revision 1.2 diff -u -p -r1.2 sandbox-rlimit.c --- sandbox-rlimit.c 23 Jun 2011 09:45:51 -0000 1.2 +++ sandbox-rlimit.c 3 Jul 2012 12:18:54 -0000 @@ -64,9 +64,11 @@ ssh_sandbox_child(struct ssh_sandbox *bo rl_zero.rlim_cur = rl_zero.rlim_max = 0; +#ifndef SANDBOX_SKIP_RLIMIT_FSIZE if (setrlimit(RLIMIT_FSIZE, &rl_zero) == -1) fatal("%s: setrlimit(RLIMIT_FSIZE, { 0, 0 }): %s", __func__, strerror(errno)); +#endif if (setrlimit(RLIMIT_NOFILE, &rl_zero) == -1) fatal("%s: setrlimit(RLIMIT_NOFILE, { 0, 0 }): %s", __func__, strerror(errno)); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jul 3 23:34:28 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 3 Jul 2012 23:34:28 +1000 Subject: possible clang (2.9) bug affecting ssh-keygen Message-ID: <20120703133428.GA22561@gate.dtucker.net> Hi all. Has anyone had any success building openssh 6.0p1 using clang 2.9? I think I found a compiler bug, at least in the 2.9 that ships with fedora 16 (i386). It causes (at least) ssh-keygen to spin indefinitely eating CPU. I've reduced it to the following test case: $ cat clang-test.c #include char hostname[64]; int main(int argc, char **argv) { gethostname(hostname, sizeof(hostname)); } $ clang -O2 -D_FORTIFY_SOURCE clang-test.c $ ./a.out [hangs] It works fine with gcc and clang 3.1 (built from source) on the same machine and clang 3.0 on ubuntu x86_64. Removing either -O2 or -D_FORTIFY_SOURCE, or moving hostname from a global to a local variable causes it to work with 2.9. Given that it seems to be fixed in the newer clang versions I don't intend filing a bug unless there's some evidence it affects newer versions too. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Wed Jul 4 00:48:15 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 3 Jul 2012 16:48:15 +0200 Subject: rlimit sandbox on cygwin In-Reply-To: <20120703124520.GA30700@gate.dtucker.net> References: <20120702152348.GA3293@gate.dtucker.net> <20120703124520.GA30700@gate.dtucker.net> Message-ID: <20120703144815.GC544@calimero.vinschen.de> On Jul 3 22:45, Darren Tucker wrote: > On Tue, Jul 03, 2012 at 01:23:48AM +1000, Darren Tucker wrote: > > Hi all. > > > > I have an old windows VM with an oldish cygwin that I use for the > > regression tests. Please use the latest one. We don't support sshd on any pre 1.7 version of Cygwin anymore. > > Investigating one of the test failures, I see that > > it's for UsePrivilegeSeparation=sandbox, and it seems to be because > > setrlimit(RLIMIT_FSIZE, ...) is not supported. > > > > IMO, this isn't a big loss, since the most useful thing in the rlimit > > "sandbox" is the descriptor limits. Can anyone see a reason not to just > > omit RLIMIT_FSIZE on cygwin? It's a no-op unless you've explicitly set > > "UsePrivilegeSeparation sandbox" in sshd_config. A function equivalent to setrlimit(RLIMIT_FSIZE) is not supported by Windows. Therefore setting or checking this limit doesn't make much sense. > On second thought, it might be better to explicitly test RLIMIT_FSIZE in > configure, like so. Sounds good to me. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Fri Jul 6 10:23:15 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 6 Jul 2012 10:23:15 +1000 Subject: rlimit sandbox on cygwin In-Reply-To: <20120703144815.GC544@calimero.vinschen.de> References: <20120702152348.GA3293@gate.dtucker.net> <20120703124520.GA30700@gate.dtucker.net> <20120703144815.GC544@calimero.vinschen.de> Message-ID: <20120706002315.GA24230@gate.dtucker.net> On Tue, Jul 03, 2012 at 04:48:15PM +0200, Corinna Vinschen wrote: [...] > Please use the latest one. We don't support sshd on any pre 1.7 > version of Cygwin anymore. OK, I've updated it. (I didn't set out to deliberately keep it old, I'd just had not particular reason to update it.) > A function equivalent to setrlimit(RLIMIT_FSIZE) is not supported > by Windows. Therefore setting or checking this limit doesn't make > much sense. > > > On second thought, it might be better to explicitly test RLIMIT_FSIZE in > > configure, like so. > > Sounds good to me. Done. It'll test setrlimit(RLIMIT_FSIZE) at configure time, and if that fails we'll simply skip it at runtime. This means that UsePriviligeSeparation=sandbox now works on Cygwin (with the weak-but-better-than-nothing rlimit sandbox). Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Fri Jul 6 18:24:40 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 6 Jul 2012 10:24:40 +0200 Subject: rlimit sandbox on cygwin In-Reply-To: <20120706002315.GA24230@gate.dtucker.net> References: <20120702152348.GA3293@gate.dtucker.net> <20120703124520.GA30700@gate.dtucker.net> <20120703144815.GC544@calimero.vinschen.de> <20120706002315.GA24230@gate.dtucker.net> Message-ID: <20120706082440.GO20942@calimero.vinschen.de> On Jul 6 10:23, Darren Tucker wrote: > On Tue, Jul 03, 2012 at 04:48:15PM +0200, Corinna Vinschen wrote: > [...] > > Please use the latest one. We don't support sshd on any pre 1.7 > > version of Cygwin anymore. > > OK, I've updated it. (I didn't set out to deliberately keep it old, I'd > just had not particular reason to update it.) > > > A function equivalent to setrlimit(RLIMIT_FSIZE) is not supported > > by Windows. Therefore setting or checking this limit doesn't make > > much sense. > > > > > On second thought, it might be better to explicitly test RLIMIT_FSIZE in > > > configure, like so. > > > > Sounds good to me. > > Done. It'll test setrlimit(RLIMIT_FSIZE) at configure time, and if that > fails we'll simply skip it at runtime. This means that > UsePriviligeSeparation=sandbox now works on Cygwin (with the > weak-but-better-than-nothing rlimit sandbox). Cool! Thanks for doing that. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rudupa at easylink.com Sat Jul 7 03:02:08 2012 From: rudupa at easylink.com (Raghu Udupa) Date: Fri, 6 Jul 2012 17:02:08 +0000 Subject: Can not login with key-exchange is chrooted sftp environment Message-ID: <10F20BC0C13B3F4C928EFD1C3A651F3637113C@PSEXMBX02.netmaster.corp.easylink.com> Hi, We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password. I am able to log-in with out password for an ssh session unlike sftp session. Is there a way to login with key-exchange only for internal-sftp with chroot? Here is the trace OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to host port 22. debug1: Connection established. debug3: Not a RSA1 key file /usr/apps1/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /usr/apps1/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /usr/apps1/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: match: OpenSSH_5.9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-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: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 127/256 debug2: bits set: 999/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /usr/apps1/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /usr/apps1/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'hsot' is known and matches the RSA host key. debug1: Found key in /usr/apps1/.ssh/known_hosts:1 debug2: bits set: 1026/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /usr/apps1/.ssh/id_rsa (0x9bd8ae8) debug2: key: /usr/apps1/.ssh/id_dsa (0x9bd8640) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /usr/apps1/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: /usr/apps1/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). Couldn't read packet: Connection reset by peer Thanks, Raghu From keisial at gmail.com Sat Jul 7 06:30:54 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 06 Jul 2012 22:30:54 +0200 Subject: Can not login with key-exchange is chrooted sftp environment In-Reply-To: <10F20BC0C13B3F4C928EFD1C3A651F3637113C@PSEXMBX02.netmaster.corp.easylink.com> References: <10F20BC0C13B3F4C928EFD1C3A651F3637113C@PSEXMBX02.netmaster.corp.easylink.com> Message-ID: <4FF74AFE.40200@gmail.com> On 06/07/12 19:02, Raghu Udupa wrote: > Hi, > > We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password. > > I am able to log-in with out password for an ssh session unlike sftp session. > > Is there a way to login with key-exchange only for internal-sftp with chroot? Are you using programs from different suites for shell session vs sftp? Both types of session are selected after the authentication, so I find strange that one would work while the other doesn't. > Here is the trace > > OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to host port 22. > debug1: Connection established. > debug3: Not a RSA1 key file /usr/apps1/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace (snip) > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /usr/apps1/.ssh/id_rsa type 1 > debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace (snip) > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /usr/apps1/.ssh/id_dsa type 2 What's the first line of those files? I would expect them to be something like -----BEGIN RSA PRIVATE KEY----- or -----BEGIN DSA PRIVATE KEY-----, but it seems it's not. Thus my suspicion that they are in a format of a different suite. If sftp can't load the key, it would obviously not be able to login. (snip) > debug1: Authentications that can continue: publickey > debug3: start over, passed a different list publickey > debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /usr/apps1/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey However, here it is sending a key... (which is rejected by the server) > debug1: Offering public key: /usr/apps1/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey and the second one is rejected, too. > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey). > Couldn't read packet: Connection reset by peer > > Thanks, > Raghu What's in the server logs for the rejection? The interesting stuff about rejected keys (eg. the file is group-writable) is logged there. Although if you can get an interactive session, it be right. Can you login through sftp if you disable the chroot? From rudupa at easylink.com Sat Jul 7 07:40:07 2012 From: rudupa at easylink.com (Raghu Udupa) Date: Fri, 6 Jul 2012 21:40:07 +0000 Subject: Can not login with key-exchange is chrooted sftp environment In-Reply-To: <4FF74AFE.40200@gmail.com> References: <10F20BC0C13B3F4C928EFD1C3A651F3637113C@PSEXMBX02.netmaster.corp.easylink.com> <4FF74AFE.40200@gmail.com> Message-ID: <10F20BC0C13B3F4C928EFD1C3A651F3637123A@PSEXMBX02.netmaster.corp.easylink.com> Thanks Angel. It was permissions issue. Authorized-keys as well as .ssh were owned by root. It is working now. Regards, Raghu -----Original Message----- From: ?ngel Gonz?lez [mailto:keisial at gmail.com] Sent: Friday, July 06, 2012 4:31 PM To: Raghu Udupa Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Can not login with key-exchange is chrooted sftp environment On 06/07/12 19:02, Raghu Udupa wrote: > Hi, > > We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password. > > I am able to log-in with out password for an ssh session unlike sftp session. > > Is there a way to login with key-exchange only for internal-sftp with chroot? Are you using programs from different suites for shell session vs sftp? Both types of session are selected after the authentication, so I find strange that one would work while the other doesn't. > Here is the trace > > OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to host port 22. > debug1: Connection established. > debug3: Not a RSA1 key file /usr/apps1/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace (snip) > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /usr/apps1/.ssh/id_rsa type 1 > debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace (snip) > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /usr/apps1/.ssh/id_dsa type 2 What's the first line of those files? I would expect them to be something like -----BEGIN RSA PRIVATE KEY----- or -----BEGIN DSA PRIVATE KEY-----, but it seems it's not. Thus my suspicion that they are in a format of a different suite. If sftp can't load the key, it would obviously not be able to login. (snip) > debug1: Authentications that can continue: publickey > debug3: start over, passed a different list publickey > debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /usr/apps1/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey However, here it is sending a key... (which is rejected by the server) > debug1: Offering public key: /usr/apps1/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey and the second one is rejected, too. > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey). > Couldn't read packet: Connection reset by peer > > Thanks, > Raghu What's in the server logs for the rejection? The interesting stuff about rejected keys (eg. the file is group-writable) is logged there. Although if you can get an interactive session, it be right. Can you login through sftp if you disable the chroot? From jonathan.P.schaaf at ge.com Tue Jul 10 03:16:46 2012 From: jonathan.P.schaaf at ge.com (Schaaf, Jonathan P (GE Healthcare)) Date: Mon, 9 Jul 2012 13:16:46 -0400 Subject: FIPS Patch for OpenSSH 6.0p1 Message-ID: <99ACB311B258474097FA3EED83ACEFAE3BD649@ALPMLVEM03.e2k.ad.ge.com> Attached to this e-mail is a patch that is likely familiar to many people on this mailing list;? It's essentially the RedHat FIPS patch updated to work with the newer release of OpenSSH.? I'm hoping it will prove useful to someone; please let me know if you have any comments or see any errors. Thanks, Jonathan From jonathan.P.schaaf at ge.com Tue Jul 10 04:46:02 2012 From: jonathan.P.schaaf at ge.com (Schaaf, Jonathan P (GE Healthcare)) Date: Mon, 9 Jul 2012 14:46:02 -0400 Subject: FIPS Patch for OpenSSH 6.0p1 Message-ID: <99ACB311B258474097FA3EED83ACEFAE3BD6FE@ALPMLVEM03.e2k.ad.ge.com> The patch is too long to include as inline text, so let's try this one more time using a link... http://jpschaaf.com/stuff/openssh-6.0p1-fips.diff -----Original Message----- From: Schaaf, Jonathan P (GE Healthcare) Sent: Monday, July 09, 2012 12:17 PM To: 'openssh-unix-dev at mindrot.org' Subject: FIPS Patch for OpenSSH 6.0p1 Attached to this e-mail is a patch that is likely familiar to many people on this mailing list;? It's essentially the RedHat FIPS patch updated to work with the newer release of OpenSSH.? I'm hoping it will prove useful to someone; please let me know if you have any comments or see any errors. Thanks, Jonathan From tobias.borgert at gmail.com Sat Jul 14 23:14:42 2012 From: tobias.borgert at gmail.com (=?iso-8859-1?Q?J=F6rg_Tobias_Borgert?=) Date: Sat, 14 Jul 2012 15:14:42 +0200 Subject: Only allow connections if file (or special condition) is present Message-ID: <008601cd61c2$a2643bc0$e72cb340$@googlemail.com> Hello! I was wondering if it possible now (or possible to implement something like that in the future) that the daemon does only accept connections if a specific file is present at the moment of the connection request. I want to achieve that a connection to my server is only possible if I plug in e.g. an USB stick (which would contain the file) and is always rejected if that pseudo-hardware-switch isn't set. My first idea was to symlink the host ceritifcate to /media/my-usb-stick/certificate-file, but that doesn't feel right. Thank you very much, Tobias From dtucker at zip.com.au Sun Jul 15 15:50:10 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 15 Jul 2012 15:50:10 +1000 Subject: Only allow connections if file (or special condition) is present In-Reply-To: <008601cd61c2$a2643bc0$e72cb340$@googlemail.com> References: <008601cd61c2$a2643bc0$e72cb340$@googlemail.com> Message-ID: <20120715055010.GA21166@gate.dtucker.net> On Sat, Jul 14, 2012 at 03:14:42PM +0200, J?rg Tobias Borgert wrote: [...] > I want to achieve that a connection to my server is only possible if I plug > in e.g. an USB stick (which would contain the file) and is always rejected > if that pseudo-hardware-switch isn't set. I can't think of any way to directly implement this in sshd_config, however: - if you platform has PAM, you could use something like "pam_listfile.so onerr=fail" or similar. - you could implement a cron job to stop or start sshd based on the presence or absence of your file, ie if the file is present and sshd not running then start it, and if the file is not present and sshd is running then stop it. > My first idea was to symlink the host ceritifcate to > /media/my-usb-stick/certificate-file, but that doesn't feel right. if you mean the host keys then it'll also stop sshd from starting if the files are not present at boot time. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From philipp.marek at linbit.com Sun Jul 15 22:15:38 2012 From: philipp.marek at linbit.com (Philipp Marek) Date: Sun, 15 Jul 2012 14:15:38 +0200 Subject: Only allow connections if file (or special condition) is present In-Reply-To: <20120715055010.GA21166@gate.dtucker.net> References: <008601cd61c2$a2643bc0$e72cb340$@googlemail.com> <20120715055010.GA21166@gate.dtucker.net> Message-ID: <201207151415.39371.philipp.marek@linbit.com> > > I want to achieve that a connection to my server is only possible if I > > plug in e.g. an USB stick (which would contain the file) and is always > > rejected if that pseudo-hardware-switch isn't set. > > I can't think of any way to directly implement this in sshd_config, > however: > - if you platform has PAM, you could use something like > "pam_listfile.so onerr=fail" or similar. > - you could implement a cron job to stop or start sshd based on the > presence or absence of your file, ie if the file is present and sshd > not running then start it, and if the file is not present and sshd is > running then stop it. Better than a cron job is a udev script; just trigger for the specific FS UUID, and then start/stop SSHD. > > My first idea was to symlink the host ceritifcate to > > /media/my-usb-stick/certificate-file, but that doesn't feel right. > > if you mean the host keys then it'll also stop sshd from starting if the > files are not present at boot time. You could put the host keys on the USB stick, and when plugging-in mount, start SSHD and umount again. Regards, Phil From tobias.borgert at gmail.com Tue Jul 17 03:51:51 2012 From: tobias.borgert at gmail.com (Tobias Borgert) Date: Mon, 16 Jul 2012 19:51:51 +0200 Subject: Only allow connections if file (or special condition) is present Message-ID: <20120716195151.bdfdabe3.tobias.borgert@gmail.com> > Better than a cron job is a udev script; just trigger for the specific FS > UUID, and then start/stop SSHD. Thank you all! I'll first try the udev script. If there is interest, I can post whether it worked or not and how I maded it. But it might take until the weekend until I find time for this. Thank you very much! From creativegenerator at gmail.com Thu Jul 19 12:52:45 2012 From: creativegenerator at gmail.com (Jeffrey Frei) Date: Wed, 18 Jul 2012 22:52:45 -0400 Subject: Random Art Size Message-ID: <64DF17B8-933C-41C6-B29F-AFFDD732B5F0@gmail.com> Dear openssh team, thanks for all your great work! I just recently discovered random art and I think it's brilliant! My VisualHostKey flag is set. It does take up a fair amount of terminal real estate, though. Would it be possible to rotate the rectangle to be horizontal so it takes up less vertical space? e.g. +----------[ RSA 2048 ]----------+ | *@E+o+ | | . ..+B +.. | | +.= o .. | | . o= . | | S | +--------------------------------+ Thanks! Jeffrey Frei From sfandino at yahoo.com Thu Jul 19 20:39:28 2012 From: sfandino at yahoo.com (Salvador Fandino) Date: Thu, 19 Jul 2012 12:39:28 +0200 Subject: While using internal sftp server, need to access files outside chroot In-Reply-To: <10F20BC0C13B3F4C928EFD1C3A651F363380FA@PSEXMBX01.netmaster.corp.easylink.com> References: <10F20BC0C13B3F4C928EFD1C3A651F3633800E@PSEXMBX01.netmaster.corp.easylink.com> <4FD0DDB2.2010108@gmail.com> <10F20BC0C13B3F4C928EFD1C3A651F36338099@PSEXMBX01.netmaster.corp.easylink.com> <4FD116F2.6020909@gmail.com> <10F20BC0C13B3F4C928EFD1C3A651F363380B8@PSEXMBX01.netmaster.corp.easylink.com> <4FD12392.3040704@gmail.com> <10F20BC0C13B3F4C928EFD1C3A651F363380FA@PSEXMBX01.netmaster.corp.easylink.com> Message-ID: <5007E3E0.9050900@yahoo.com> On 06/08/2012 12:06 AM, Raghu Udupa wrote: > Angel, > > I do not think I can chroot to that dir( basically it is a queue directory that contains all incoming files from various users queued for subsequent processing). After thinking a little bit more, have a perl daemon to monitor inboxes and move it the common queue dir is the best solution(your 2nd idea). This requires minimal customization on ssh-side and is very clean.... > If you are going to use Perl, then consider using the Net::SFTP::Server module from CPAN. It implements an SFTP server in Perl and can be easily extended to perform some action after every put action. See also https://github.com/salva/p5-Net-SFTP-Server/blob/master/examples/sftp-server-rename-after-put.pl From micchie at sfc.wide.ad.jp Sat Jul 21 00:06:33 2012 From: micchie at sfc.wide.ad.jp (Michio Honda) Date: Fri, 20 Jul 2012 16:06:33 +0200 Subject: SCTP support for OpenSSH Message-ID: Dear all, I just subscribed too, The Linux SCTP implementation has recently supported AUTO-ASCONF with a default_auto_asconf sysctl parameter and setsockopt(). Cheers, - Michio > Dear all, > I just subscribed, therefore I can't answer inline the earlier messages... > The FreeBSD SCTP implementation (and I think also the Linux implementation) support > a feature called AUTO-ASCONF. If a node gets a new IP-address, or gives up one, > it is automatically added or removed from the association. So you don't need > to involve DNS in this. And you do not need to write OS specific code to deal > with local address changes. > Best regards > Michael From carstenmattner at gmail.com Thu Jul 26 00:48:36 2012 From: carstenmattner at gmail.com (Carsten Mattner) Date: Wed, 25 Jul 2012 16:48:36 +0200 Subject: seccomp_filter Message-ID: Can I configure openssh with --sandbox=seccomp_filter and have it still run on older kernels with sandboxing via rlimit? I'm asking from a linux distro packaging point of view. Does --sandbox=seccomp_filter keep the rlimit sandbox? It looks to me as if I can only link in one of the sandbox plugins. An openssh build with seccomp_filter enabled will probably have no sandbox at all on linux < 3.5. Is that correct? Would it start up linux 3.4 or 3.2 at all? From djm at mindrot.org Thu Jul 26 09:26:12 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Jul 2012 09:26:12 +1000 (EST) Subject: seccomp_filter In-Reply-To: References: Message-ID: On Wed, 25 Jul 2012, Carsten Mattner wrote: > Can I configure openssh with --sandbox=seccomp_filter and have it still run > on older kernels with sandboxing via rlimit? I'm asking from a linux > distro packaging > point of view. Does --sandbox=seccomp_filter keep the rlimit sandbox? > It looks to > me as if I can only link in one of the sandbox plugins. > > An openssh build with seccomp_filter enabled will probably have no sandbox > at all on linux < 3.5. Is that correct? Would it start up linux 3.4 or > 3.2 at all? HEAD will fallback to the rlimit pseudo-sandbox if seccomp was enabled at compile-time but is not available at runtime. openssh-6.0 will fatal() for these cases. -d From carstenmattner at gmail.com Thu Jul 26 21:50:41 2012 From: carstenmattner at gmail.com (Carsten Mattner) Date: Thu, 26 Jul 2012 13:50:41 +0200 Subject: seccomp_filter In-Reply-To: References: Message-ID: On Thu, Jul 26, 2012 at 1:26 AM, Damien Miller wrote: > > > On Wed, 25 Jul 2012, Carsten Mattner wrote: > >> Can I configure openssh with --sandbox=seccomp_filter and have it >> still run on older kernels with sandboxing via rlimit? I'm asking >> from a linux distro packaging point of view. Does >> --sandbox=seccomp_filter keep the rlimit sandbox? It looks to me as >> if I can only link in one of the sandbox plugins. >> >> An openssh build with seccomp_filter enabled will probably have no >> sandbox at all on linux < 3.5. Is that correct? Would it start up >> linux 3.4 or 3.2 at all? > > HEAD will fallback to the rlimit pseudo-sandbox if seccomp was enabled at > compile-time but is not available at runtime. openssh-6.0 will fatal() for > these cases. That sounds good. Is it available in a single commit I could backport until the next release? Is it correct that November 2012 is the release date for 6.1? From djm at mindrot.org Thu Jul 26 21:57:16 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Jul 2012 21:57:16 +1000 (EST) Subject: seccomp_filter In-Reply-To: References: Message-ID: On Thu, 26 Jul 2012, Carsten Mattner wrote: > > HEAD will fallback to the rlimit pseudo-sandbox if seccomp was enabled at > > compile-time but is not available at runtime. openssh-6.0 will fatal() for > > these cases. > > That sounds good. Is it available in a single commit I could backport > until the next release? Is it correct that November 2012 is the > release date for 6.1? It will probably be sooner than that. Perhaps late this month even. http://hg.mindrot.org/openssh/raw-rev/d8de6b1ebec9 should be all you need. -d From alon.barlev at gmail.com Sun Jul 29 04:23:17 2012 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 28 Jul 2012 21:23:17 +0300 Subject: [PATCH] ssh-keygen: support public key import/export using SubjectPublicKeyInfo Message-ID: <1343499797-2296-1-git-send-email-alon.barlev@gmail.com> ssh-keygen already supports importing and exporting ssh keys using various formats. The "-m PEM" which should have been the easiest to be used with various of external application expects PKCS#1 encoded key, while many applications use SubjectPublicKeyInfo encoded key. This change adds SubjectPublicKeyInfo support, to ease integration with applications. Examples: ## convert SubjectPublicKeyInfo public key to SSH public key $ openssl req -newkey rsa:2048 -nodes -pubkey -subj "/CN=test" \ -noout -keyout /dev/null | \ ssh-keygen -i -m SUBJECTINFO -f /proc/self/fd/0 ## convert X.509 certificate to SSH public key $ openssl req -newkey rsa:2048 -nodes -x509 -subj "/CN=test" \ -keyout /dev/null | openssl x509 -pubkey -noout | \ ssh-keygen -i -m SUBJECTINFO -f /proc/self/fd/0 ## convert SSH public key to SubjectPublicKeyInfo public key $ ssh-keygen -e -m SUBJECTINFO -f ~/.ssh/id_rsa.pub | \ openssl rsa -pubin -text Signed-off-by: Alon Bar-Lev --- ssh-keygen.1 | 6 +++- ssh-keygen.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 69 insertions(+), 3 deletions(-) diff --git a/ssh-keygen.1 b/ssh-keygen.1 index 41da207..88451ac 100644 --- a/ssh-keygen.1 +++ b/ssh-keygen.1 @@ -334,9 +334,11 @@ The supported key formats are: (RFC 4716/SSH2 public or private key), .Dq PKCS8 (PEM PKCS8 public key) -or .Dq PEM -(PEM public key). +(PEM public key) +or +.Dq SUBJECTINFO +(SubjectPublicKeyInfo public key). The default conversion format is .Dq RFC4716 . .It Fl N Ar new_passphrase diff --git a/ssh-keygen.c b/ssh-keygen.c index 5fcd3a1..072c49a 100644 --- a/ssh-keygen.c +++ b/ssh-keygen.c @@ -137,7 +137,8 @@ int convert_from = 0; enum { FMT_RFC4716, FMT_PKCS8, - FMT_PEM + FMT_PEM, + FMT_SUBJECTINFO } convert_format = FMT_RFC4716; int print_public = 0; int print_generic = 0; @@ -330,6 +331,27 @@ do_convert_to_pem(Key *k) } static void +do_convert_to_subjectinfo(Key *k) +{ + switch (key_type_plain(k->type)) { + case KEY_RSA: + if (!PEM_write_RSA_PUBKEY(stdout, k->rsa)) + fatal("PEM_write_RSAPublicKey failed"); + break; +#if notyet /* OpenSSH 0.9.8 lacks this function */ + case KEY_DSA: + if (!PEM_write_DSA_PUBKEY(stdout, k->dsa)) + fatal("PEM_write_DSAPublicKey failed"); + break; +#endif + /* XXX ECDSA? */ + default: + fatal("%s: unsupported key type %s", __func__, key_type(k)); + } + exit(0); +} + +static void do_convert_to(struct passwd *pw) { Key *k; @@ -360,6 +382,9 @@ do_convert_to(struct passwd *pw) case FMT_PEM: do_convert_to_pem(k); break; + case FMT_SUBJECTINFO: + do_convert_to_subjectinfo(k); + break; default: fatal("%s: unknown key format %d", __func__, convert_format); } @@ -631,6 +656,38 @@ do_convert_from_pem(Key **k, int *private) } static void +do_convert_from_subjectinfo(Key **k, int *private) +{ + FILE *fp; + RSA *rsa; +#ifdef notyet + DSA *dsa; +#endif + + if ((fp = fopen(identity_file, "r")) == NULL) + fatal("%s: %s: %s", __progname, identity_file, strerror(errno)); + if ((rsa = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) != NULL) { + *k = key_new(KEY_UNSPEC); + (*k)->type = KEY_RSA; + (*k)->rsa = rsa; + fclose(fp); + return; + } +#if notyet /* OpenSSH 0.9.8 lacks this function */ + rewind(fp); + if ((dsa = PEM_read_DSA_PUBKEY(fp, NULL, NULL, NULL)) != NULL) { + *k = key_new(KEY_UNSPEC); + (*k)->type = KEY_DSA; + (*k)->dsa = dsa; + fclose(fp); + return; + } + /* XXX ECDSA */ +#endif + fatal("%s: unrecognised subjectinfo public key format", __func__); +} + +static void do_convert_from(struct passwd *pw) { Key *k = NULL; @@ -652,6 +709,9 @@ do_convert_from(struct passwd *pw) case FMT_PEM: do_convert_from_pem(&k, &private); break; + case FMT_SUBJECTINFO: + do_convert_from_subjectinfo(&k, &private); + break; default: fatal("%s: unknown key format %d", __func__, convert_format); } @@ -2005,6 +2065,10 @@ main(int argc, char **argv) convert_format = FMT_PEM; break; } + if (strcasecmp(optarg, "SUBJECTINFO") == 0) { + convert_format = FMT_SUBJECTINFO; + break; + } fatal("Unsupported conversion format \"%s\"", optarg); case 'n': cert_principals = optarg; -- 1.7.8.6 From djm at mindrot.org Mon Jul 30 10:24:38 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 30 Jul 2012 10:24:38 +1000 (EST) Subject: [PATCH] ssh-keygen: support public key import/export using SubjectPublicKeyInfo In-Reply-To: <1343499797-2296-1-git-send-email-alon.barlev@gmail.com> References: <1343499797-2296-1-git-send-email-alon.barlev@gmail.com> Message-ID: On Sat, 28 Jul 2012, Alon Bar-Lev wrote: > ssh-keygen already supports importing and exporting ssh keys using > various formats. > > The "-m PEM" which should have been the easiest to be used with > various of external application expects PKCS#1 encoded key, while > many applications use SubjectPublicKeyInfo encoded key. > > This change adds SubjectPublicKeyInfo support, to ease integration > with applications. I've not heard the term "SubjectPublicKeyInfo" used to refer to a public key format before, but what the format you seem to be importing and exporting seems to be what we implement as PKCS8, though I think this might be a misnomer. If you s/SUBJECTINFO/PKCS8/ in your examples then they should work. > Examples: > ## convert SubjectPublicKeyInfo public key to SSH public key > $ openssl req -newkey rsa:2048 -nodes -pubkey -subj "/CN=test" \ > -noout -keyout /dev/null | \ > ssh-keygen -i -m SUBJECTINFO -f /proc/self/fd/0 > > ## convert X.509 certificate to SSH public key > $ openssl req -newkey rsa:2048 -nodes -x509 -subj "/CN=test" \ > -keyout /dev/null | openssl x509 -pubkey -noout | \ > ssh-keygen -i -m SUBJECTINFO -f /proc/self/fd/0 > > ## convert SSH public key to SubjectPublicKeyInfo public key > $ ssh-keygen -e -m SUBJECTINFO -f ~/.ssh/id_rsa.pub | \ > openssl rsa -pubin -text -d From alon.barlev at gmail.com Mon Jul 30 16:13:23 2012 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 30 Jul 2012 09:13:23 +0300 Subject: [PATCH] ssh-keygen: support public key import/export using SubjectPublicKeyInfo In-Reply-To: References: <1343499797-2296-1-git-send-email-alon.barlev@gmail.com> Message-ID: On Mon, Jul 30, 2012 at 3:24 AM, Damien Miller wrote: > On Sat, 28 Jul 2012, Alon Bar-Lev wrote: > >> ssh-keygen already supports importing and exporting ssh keys using >> various formats. >> >> The "-m PEM" which should have been the easiest to be used with >> various of external application expects PKCS#1 encoded key, while >> many applications use SubjectPublicKeyInfo encoded key. >> >> This change adds SubjectPublicKeyInfo support, to ease integration >> with applications. > > I've not heard the term "SubjectPublicKeyInfo" used to refer to a > public key format before, but what the format you seem to be importing > and exporting seems to be what we implement as PKCS8, though I think > this might be a misnomer. > > If you s/SUBJECTINFO/PKCS8/ in your examples then they should work. Thank you, my bad. Alon.