From jon.cave at mwrinfosecurity.com Mon Dec 2 01:28:54 2013 From: jon.cave at mwrinfosecurity.com (Jon Cave) Date: Sun, 1 Dec 2013 14:28:54 +0000 Subject: chacha20+poly1305 authenticated encryption In-Reply-To: References: Message-ID: <529B47A6.4000905@mwrinfosecurity.com> There is a small typo in the new protocol document where it mistakenly references "Poly1306". - Jon Index: usr.bin/ssh/PROTOCOL.chacha20poly1305 =================================================================== RCS file: /cvs/src/usr.bin/ssh/PROTOCOL.chacha20poly1305,v retrieving revision 1.1 diff -u -r1.1 PROTOCOL.chacha20poly1305 --- usr.bin/ssh/PROTOCOL.chacha20poly1305 21 Nov 2013 00:45:43 -0000 1.1 +++ usr.bin/ssh/PROTOCOL.chacha20poly1305 1 Dec 2013 14:15:21 -0000 @@ -47,7 +47,7 @@ the MAC. By using an independently-keyed cipher instance to encrypt the length, an active attacker seeking to exploit the packet input handling as a decryption oracle can learn nothing about the payload contents or -its MAC (assuming key derivation, ChaCha20 and Poly1306 are secure). +its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure). The AEAD is constructed as follows: for each packet, generate a Poly1305 key by taking the first 256 bits of ChaCha20 stream output generated From djm at mindrot.org Mon Dec 2 13:50:35 2013 From: djm at mindrot.org (Damien Miller) Date: Mon, 2 Dec 2013 13:50:35 +1100 (EST) Subject: chacha20+poly1305 authenticated encryption In-Reply-To: <529B47A6.4000905@mwrinfosecurity.com> References: <529B47A6.4000905@mwrinfosecurity.com> Message-ID: committed - thanks On Sun, 1 Dec 2013, Jon Cave wrote: > There is a small typo in the new protocol document where it mistakenly > references "Poly1306". > > - Jon > > Index: usr.bin/ssh/PROTOCOL.chacha20poly1305 > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/PROTOCOL.chacha20poly1305,v > retrieving revision 1.1 > diff -u -r1.1 PROTOCOL.chacha20poly1305 > --- usr.bin/ssh/PROTOCOL.chacha20poly1305 21 Nov 2013 00:45:43 -0000 1.1 > +++ usr.bin/ssh/PROTOCOL.chacha20poly1305 1 Dec 2013 14:15:21 -0000 > @@ -47,7 +47,7 @@ > the MAC. By using an independently-keyed cipher instance to encrypt the > length, an active attacker seeking to exploit the packet input handling > as a decryption oracle can learn nothing about the payload contents or > -its MAC (assuming key derivation, ChaCha20 and Poly1306 are secure). > +its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure). > > The AEAD is constructed as follows: for each packet, generate a Poly1305 > key by taking the first 256 bits of ChaCha20 stream output generated > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From imorgan at nas.nasa.gov Tue Dec 3 06:12:44 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 2 Dec 2013 11:12:44 -0800 Subject: openssh-bugs mailing list archives In-Reply-To: References: <20131120195027.GE8747@linux124.nas.nasa.gov> Message-ID: <20131202191244.GL8715@linux124.nas.nasa.gov> On Thu, Nov 21, 2013 at 10:15:51 +1100, Damien Miller wrote: > On Wed, 20 Nov 2013, Iain Morgan wrote: > > > Hello, > > > > Is there a problem with the openssh-bugs mailing list? I'm not > > subscribed to it, but watch the marc.info archive instead. The last > > message in the archive is the creation of bz#2163 on October 10th. The > > archive at gmane.org likewise seems to have stopped at the same time. > > > > I at first thought that this was just a lull in activity, but it's gone > > on rather long. Poking around at bugzilla.mindrot.org, I see that new > > bugs have been created since then, so this is obviously not the > > explanation. > > > > Is the list simply no longer being archived? > > No, but a security upgrade brought with it some new behaviour that > broke the archive. I've just fixed it, so new messages will be recorded > properly. Unfortunately, I'm not sure of any easy way to get the ones > missed over the last month added. > > -d This, unfortunately, appears to still be broken. Nothing has appeared in the archive (both lists.mindrot.org and marc.info) since the one test message on November 20th. -- Iain Morgan From djm at mindrot.org Wed Dec 4 15:43:00 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 Dec 2013 15:43:00 +1100 (EST) Subject: openssh-bugs mailing list archives In-Reply-To: <20131202191244.GL8715@linux124.nas.nasa.gov> References: <20131120195027.GE8747@linux124.nas.nasa.gov> <20131202191244.GL8715@linux124.nas.nasa.gov> Message-ID: On Mon, 2 Dec 2013, Iain Morgan wrote: > > No, but a security upgrade brought with it some new behaviour that > > broke the archive. I've just fixed it, so new messages will be recorded > > properly. Unfortunately, I'm not sure of any easy way to get the ones > > missed over the last month added. > > This, unfortunately, appears to still be broken. Nothing has appeared in > the archive (both lists.mindrot.org and marc.info) since the one test > message on November 20th. Fixed. For reals this time. -d From djm at mindrot.org Thu Dec 5 15:21:34 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Dec 2013 15:21:34 +1100 (EST) Subject: openssh-bugs mailing list archives In-Reply-To: <529FFE15.1070507@gmail.com> References: <20131120195027.GE8747@linux124.nas.nasa.gov> <20131202191244.GL8715@linux124.nas.nasa.gov> <529FFE15.1070507@gmail.com> Message-ID: http://lists.mindrot.org/pipermail/openssh-bugs/2013-December/thread.html has updates from this mornings bug-whacking sessions. On Wed, 4 Dec 2013, Kevin Brott wrote: > On 2013-12-03 20:43, Damien Miller wrote: > > On Mon, 2 Dec 2013, Iain Morgan wrote: > > > > No, but a security upgrade brought with it some new behaviour that > > > > broke the archive. I've just fixed it, so new messages will be recorded > > > > properly. Unfortunately, I'm not sure of any easy way to get the ones > > > > missed over the last month added. > > > This, unfortunately, appears to still be broken. Nothing has appeared in > > > the archive (both lists.mindrot.org and marc.info) since the one test > > > message on November 20th. > > Fixed. For reals this time. > > > > > > From kevin.brott at gmail.com Thu Dec 5 15:29:16 2013 From: kevin.brott at gmail.com (Kevin Brott) Date: Wed, 04 Dec 2013 20:29:16 -0800 Subject: openssh-bugs mailing list archives In-Reply-To: References: <20131120195027.GE8747@linux124.nas.nasa.gov> <20131202191244.GL8715@linux124.nas.nasa.gov> Message-ID: <52A0011C.5040409@gmail.com> On 2013-12-03 20:43, Damien Miller wrote: > On Mon, 2 Dec 2013, Iain Morgan wrote: > >>> No, but a security upgrade brought with it some new behaviour that >>> broke the archive. I've just fixed it, so new messages will be recorded >>> properly. Unfortunately, I'm not sure of any easy way to get the ones >>> missed over the last month added. >> This, unfortunately, appears to still be broken. Nothing has appeared in >> the archive (both lists.mindrot.org and marc.info) since the one test >> message on November 20th. > Fixed. For reals this time. > > -d > -- # include /* Kevin Brott */ From kevin.brott at gmail.com Thu Dec 5 15:30:47 2013 From: kevin.brott at gmail.com (Kevin Brott) Date: Wed, 04 Dec 2013 20:30:47 -0800 Subject: openssh-bugs mailing list archives In-Reply-To: References: <20131120195027.GE8747@linux124.nas.nasa.gov> <20131202191244.GL8715@linux124.nas.nasa.gov> <529FFE15.1070507@gmail.com> Message-ID: <52A00177.1090001@gmail.com> On 2013-12-04 20:21, Damien Miller wrote: > http://lists.mindrot.org/pipermail/openssh-bugs/2013-December/thread.html > > has updates from this mornings bug-whacking sessions. > > On Wed, 4 Dec 2013, Kevin Brott wrote: > >> On 2013-12-03 20:43, Damien Miller wrote: >>> On Mon, 2 Dec 2013, Iain Morgan wrote: >>>>> No, but a security upgrade brought with it some new behaviour that >>>>> broke the archive. I've just fixed it, so new messages will be recorded >>>>> properly. Unfortunately, I'm not sure of any easy way to get the ones >>>>> missed over the last month added. >>>> This, unfortunately, appears to still be broken. Nothing has appeared in >>>> the archive (both lists.mindrot.org and marc.info) since the one test >>>> message on November 20th. >>> Fixed. For reals this time. >>> So it does - apparently I needed to force-reload the page. :p -- # include /* Kevin Brott */ From djm at mindrot.org Sat Dec 7 17:40:38 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 7 Dec 2013 17:40:38 +1100 (EST) Subject: New key type (ed25519) and private key format Message-ID: Hi, Markus has just committed a few changes that add support for the Ed25519 signature algorithm[1] as a new private key type. This algorithm has a few benefits: it is fast (comparable to ECDSA and RSA), offers 256-bit security and doesn't require random numbers to generate a signature. This last property means it completely avoids (EC-)DSA's horrible, private-key leaking problem when fed from a predictable random number generator. Ed25519 is not supported in OpenSSL, so we used a public-domain implementation (from SUPERCOP). Unfortunately this means that we could not use the PEM key format that we have used for RSA, DSA and ECDSA keys until now, so Markus made a new one. The new key format looks a lot like the old one (a blob of base64 encoded key material with beginning and end markers), but offers quite a bit more protection to the key from offline attacks against the passphrase. The new format uses a bcrypt-based key derivation function that makes is brute-force attacks against stolen private keys far slower. So far, it is only required for Ed25519 keys but it is possible to request it for other key types too by adding the '-o' flag to ssh-keygen when generating a key. It's also possible to convert existing keys to the new format by specifying the -o flag when changing the passphrase ('-p'). Ed25519 and the new key format to support it represented a fair amount of new code in OpenSSH, so please try out a snapshot dated 20131207 or later. There are certain to be some portability bugs in there that need to be shaken out... -d [1] http://ed25519.cr.yp.to/ed25519-20110926.pdf From loganaden at gmail.com Sat Dec 7 21:33:12 2013 From: loganaden at gmail.com (Loganaden Velvindron) Date: Sat, 7 Dec 2013 14:33:12 +0400 Subject: New key type (ed25519) and private key format In-Reply-To: References: Message-ID: On Sat, Dec 7, 2013 at 10:40 AM, Damien Miller wrote: > Hi, > > Markus has just committed a few changes that add support for the Ed25519 > signature algorithm[1] as a new private key type. This algorithm has a > few benefits: it is fast (comparable to ECDSA and RSA), offers 256-bit > security and doesn't require random numbers to generate a signature. > This last property means it completely avoids (EC-)DSA's horrible, > private-key leaking problem when fed from a predictable random number > generator. > > Ed25519 is not supported in OpenSSL, so we used a public-domain > implementation (from SUPERCOP). Unfortunately this means that we could > not use the PEM key format that we have used for RSA, DSA and ECDSA keys > until now, so Markus made a new one. > > The new key format looks a lot like the old one (a blob of base64 > encoded key material with beginning and end markers), but offers quite > a bit more protection to the key from offline attacks against the > passphrase. The new format uses a bcrypt-based key derivation function > that makes is brute-force attacks against stolen private keys far > slower. > > So far, it is only required for Ed25519 keys but it is possible to > request it for other key types too by adding the '-o' flag to ssh-keygen > when generating a key. It's also possible to convert existing keys to > the new format by specifying the -o flag when changing the passphrase > ('-p'). > > Ed25519 and the new key format to support it represented a fair amount > of new code in OpenSSH, so please try out a snapshot dated 20131207 or > later. There are certain to be some portability bugs in there that need > to be shaken out... > > -d > > [1] http://ed25519.cr.yp.to/ed25519-20110926.pdf Awesome. Tested. I had installed the latest from cvs using --prefix=/usr/local It works fine, but it doesn't generate the ed25519 key upon make install, thus preventing me from launching sshd. I've attached a diff on bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=2179 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From vinschen at redhat.com Sat Dec 7 22:33:49 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 7 Dec 2013 12:33:49 +0100 Subject: Potential crash due to missing declaration of strerror Message-ID: <20131207113349.GA19145@calimero.vinschen.de> Hi, I've just stumbled over this gcc warning while building OpenSSH: openbsd-compat/bsd-setres_id.c:41:3: warning: implicit declaration of function ?strerror? [-Wimplicit-function-declaration] error("setregid %u: %.100s", rgid, strerror(errno)); ^ openbsd-compat/bsd-setres_id.c:41:3: warning: format ?%s? expects argument of type ?char *?, but argument 3 has type ?int? [-Wformat=] This almost certainly results in a crash on systems with sizeof(char*) > sizeof(int), like on practically all 64 bit systems. This simple patch fixes it: Index: openbsd-compat/bsd-setres_id.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-setres_id.c,v retrieving revision 1.1 diff -u -p -r1.1 bsd-setres_id.c --- openbsd-compat/bsd-setres_id.c 5 Nov 2012 06:04:37 -0000 1.1 +++ openbsd-compat/bsd-setres_id.c 7 Dec 2013 10:57:31 -0000 @@ -22,6 +22,7 @@ #include #include +#include #include "log.h" Hope that helps, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From naddy at mips.inka.de Sat Dec 7 23:15:02 2013 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat, 7 Dec 2013 12:15:02 +0000 (UTC) Subject: New key type (ed25519) and private key format References: Message-ID: Damien Miller wrote: > Markus has just committed a few changes that add support for the Ed25519 > signature algorithm[1] as a new private key type. This algorithm has a > few benefits: it is fast (comparable to ECDSA and RSA), offers 256-bit > security and doesn't require random numbers to generate a signature. Actually DJB et al.'s paper claims 128-bit security. Looking at myproposal.h, I see that the new algorithm is called "ssh-ed25519" without "@openssh.com". Is that intentional or an oversight? -- Christian "naddy" Weisgerber naddy at mips.inka.de From aris at badcode.be Sun Dec 8 02:00:35 2013 From: aris at badcode.be (Aris Adamantiadis) Date: Sat, 07 Dec 2013 16:00:35 +0100 Subject: New key type (ed25519) and private key format In-Reply-To: References: Message-ID: <52A33813.9080507@badcode.be> Le 7/12/13 07:40, Damien Miller a ?crit : > Hi, > > Ed25519 is not supported in OpenSSL, so we used a public-domain > implementation (from SUPERCOP). Unfortunately this means that we could > not use the PEM key format that we have used for RSA, DSA and ECDSA keys > until now, so Markus made a new one. > > The new key format looks a lot like the old one (a blob of base64 > encoded key material with beginning and end markers), but offers quite > a bit more protection to the key from offline attacks against the > passphrase. The new format uses a bcrypt-based key derivation function > that makes is brute-force attacks against stolen private keys far > slower. > Hi Damien, Markus, I do not understand why Ed25519 not being in Openssl couldn't let you use the pem-like format described in RFC4716. In fact that would have been a good occasion of getting rid of the complex PEM decoder from libcrypto and implement your own (with relevant subset of ASN.1 decoding). Maybe you did not want something as complex as PEM. When designing your new format, did you take in consideration some of the criticism over the existing PEM format to improve it ? One of the functionalities I could see useful would be to embed the public key authenticated but not encrypted into the key file. That way, it is always possible to determine if a key is useful before asking the passphrase to the user (current workaround needs the actual encrypted key and a cleartext public key file, which can be confusing). The key format of putty could have been a good candidate. Some food for thoughts on [1]. Did you publish some specs already ? I cannot find it yet on openssh.org. Regards and good week-end, Aris [1] http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html From mfriedl at gmail.com Sun Dec 8 03:35:34 2013 From: mfriedl at gmail.com (Markus Friedl) Date: Sat, 7 Dec 2013 17:35:34 +0100 Subject: New key type (ed25519) and private key format In-Reply-To: <52A33813.9080507@badcode.be> References: <52A33813.9080507@badcode.be> Message-ID: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.key > Am 07.12.2013 um 16:00 schrieb Aris Adamantiadis : > > Le 7/12/13 07:40, Damien Miller a ?crit : >> Hi, >> >> Ed25519 is not supported in OpenSSL, so we used a public-domain >> implementation (from SUPERCOP). Unfortunately this means that we could >> not use the PEM key format that we have used for RSA, DSA and ECDSA keys >> until now, so Markus made a new one. >> >> The new key format looks a lot like the old one (a blob of base64 >> encoded key material with beginning and end markers), but offers quite >> a bit more protection to the key from offline attacks against the >> passphrase. The new format uses a bcrypt-based key derivation function >> that makes is brute-force attacks against stolen private keys far >> slower. > Hi Damien, Markus, > > I do not understand why Ed25519 not being in Openssl couldn't let you > use the pem-like format described in RFC4716. In fact that would have > been a good occasion of getting rid of the complex PEM decoder from > libcrypto and implement your own (with relevant subset of ASN.1 > decoding). Maybe you did not want something as complex as PEM. > > When designing your new format, did you take in consideration some of > the criticism over the existing PEM format to improve it ? One of the > functionalities I could see useful would be to embed the public key > authenticated but not encrypted into the key file. That way, it is > always possible to determine if a key is useful before asking the > passphrase to the user (current workaround needs the actual encrypted > key and a cleartext public key file, which can be confusing). The key > format of putty could have been a good candidate. Some food for thoughts > on [1]. > > Did you publish some specs already ? I cannot find it yet on openssh.org. > > Regards and good week-end, > > Aris > > [1] > http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Sun Dec 8 08:23:15 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 8 Dec 2013 08:23:15 +1100 (EST) Subject: Potential crash due to missing declaration of strerror In-Reply-To: <20131207113349.GA19145@calimero.vinschen.de> References: <20131207113349.GA19145@calimero.vinschen.de> Message-ID: applied - thanks. On Sat, 7 Dec 2013, Corinna Vinschen wrote: > Hi, > > I've just stumbled over this gcc warning while building OpenSSH: > > openbsd-compat/bsd-setres_id.c:41:3: warning: implicit declaration of function ?strerror? [-Wimplicit-function-declaration] > error("setregid %u: %.100s", rgid, strerror(errno)); > ^ > openbsd-compat/bsd-setres_id.c:41:3: warning: format ?%s? expects argument of type ?char *?, but argument 3 has type ?int? [-Wformat=] > > This almost certainly results in a crash on systems with > sizeof(char*) > sizeof(int), like on practically all 64 bit systems. > > This simple patch fixes it: > > Index: openbsd-compat/bsd-setres_id.c > =================================================================== > RCS file: /cvs/openssh/openbsd-compat/bsd-setres_id.c,v > retrieving revision 1.1 > diff -u -p -r1.1 bsd-setres_id.c > --- openbsd-compat/bsd-setres_id.c 5 Nov 2012 06:04:37 -0000 1.1 > +++ openbsd-compat/bsd-setres_id.c 7 Dec 2013 10:57:31 -0000 > @@ -22,6 +22,7 @@ > > #include > #include > +#include > > #include "log.h" > > > Hope that helps, > Corinna > From djm at mindrot.org Mon Dec 9 12:45:26 2013 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Dec 2013 12:45:26 +1100 (EST) Subject: New key type (ed25519) and private key format In-Reply-To: References: Message-ID: On Sat, 7 Dec 2013, Damien Miller wrote: > Hi, > > Markus has just committed a few changes that add support for the Ed25519 > signature algorithm[1] as a new private key type. This algorithm has a > few benefits: it is fast (comparable to ECDSA and RSA), offers 256-bit > security Turns out that I'm wrong about this: Ed25519 offers 128 bit security, not 256. -d From yuri at rawbw.com Wed Dec 11 20:28:03 2013 From: yuri at rawbw.com (Yuri) Date: Wed, 11 Dec 2013 01:28:03 -0800 Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? Message-ID: <52A83023.5000307@rawbw.com> I have a client host that I don't have access to now, which attempts to establish ssh connection back to my BSD server using the private key. Client runs this command: /usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p $HPORT $HUSER@$HOST -R $LPORT:localhost:$LPORT -N On the server debug log looks like this: Connection from NNN.NNN.NNN.NNN port 43567 debug1: HPN Disabled: 0, HPN Buffer Size: 65536 debug1: Client protocol version 2.0; client software version OpenSSH_5.9p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5* debug1: Remote is not HPN-aware debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515 debug1: permanently_set_uid: 22/22 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client->server aes128-ctr hmac-md5 none [preauth] debug1: kex: server->client aes128-ctr hmac-md5 none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Connection closed by NNN.NNN.NNN.NNN [preauth] Client breaks connection right after 'expecting SSH2_MSG_NEWKEYS'. I can always successfully connect to this server myself, and successful log continuation looks like this: debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user minsk service ssh-connection method none debug1: attempt 0 failures 0 ... When I have set this client up, it was able to connect to similar BSD server system over the local net. So it does have the correct key. But over the internet connection now fails like this. What can possibly cause client to break connection after 'expecting SSH2_MSG_NEWKEYS', and not proceed to SSH2_MSG_NEWKEYS? I tried the same with similar linux client system running in VM, and it succeeds to connect. I also tried to downgrade server from version 6.2 to 5.8, and both versions exhibit the same problem. Yuri From benjaminfras at netbens.de Wed Dec 11 20:28:43 2013 From: benjaminfras at netbens.de (=?utf-8?Q?Benjamin_Fras?=) Date: Wed, 11 Dec 2013 10:28:43 +0100 Subject: OpenSSH 6.3p1 Smartcard-Support Message-ID: Hi there, has anybody managed to get the eToken Pro Anywhere work with SSH? I'm using the latest SafeNetAuthentication drivers available for Ubuntu 64bit (8.3) and everything is working just fine except for ssh. I can use the eToken for logging in, openvpn, rdestkop, etc. but it seems ssh does not recognize the device properly. The command "ssh -I /usr/lib/libeToken.so.8 user at hostname" is accessing the eToken somehow, as indicated by the blinking led. But it doesn't ask for a pin and thus the connection is aborted due to "no authentication methods available". If you have any ideas please let me know. I've already spent hours of trying and nothing actually worked. Thanks in advance, Ben From dtucker at zip.com.au Wed Dec 11 21:09:35 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Dec 2013 21:09:35 +1100 Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? In-Reply-To: <52A83023.5000307@rawbw.com> References: <52A83023.5000307@rawbw.com> Message-ID: On Wed, Dec 11, 2013 at 8:28 PM, Yuri wrote: > I have a client host that I don't have access to now, which attempts to > establish ssh connection back to my BSD server using the private key. > Client runs this command: > /usr/bin/ssh -i ~/.ssh/my_key_rsa -o "ExitOnForwardFailure yes" -p $HPORT > $HUSER@$HOST -R $LPORT:localhost:$LPORT -N > > On the server debug log looks like this: > Connection from NNN.NNN.NNN.NNN port 43567 > debug1: HPN Disabled: 0, HPN Buffer Size: 65536 That's a modified ssh server. Can you reproduce the problem with a stock openssh from openssh.com? You might get some more clues if you run the server in debug mode (/path/to/sshd -ddde). -- 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 djm at mindrot.org Wed Dec 11 21:25:00 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Dec 2013 21:25:00 +1100 (EST) Subject: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: On Wed, 11 Dec 2013, Benjamin Fras wrote: > Hi there, > > has anybody managed to get the eToken Pro Anywhere work with SSH? I'm > using the latest SafeNetAuthentication drivers available for Ubuntu > 64bit (8.3) and everything is working just fine except for ssh. I > can use the eToken for logging in, openvpn, rdestkop, etc. but it > seems ssh does not recognize the device properly. The command "ssh > -I /usr/lib/libeToken.so.8 user at hostname" is accessing the eToken > somehow, as indicated by the blinking led. But it doesn't ask for > a pin and thus the connection is aborted due to "no authentication > methods available". You'll need to post at least a debug trace if you want help. -d From yuri at rawbw.com Wed Dec 11 22:17:10 2013 From: yuri at rawbw.com (Yuri) Date: Wed, 11 Dec 2013 03:17:10 -0800 Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? In-Reply-To: References: <52A83023.5000307@rawbw.com> Message-ID: <52A849B6.8020505@rawbw.com> On 12/11/2013 02:09, Darren Tucker wrote: > That's a modified ssh server. Can you reproduce the problem with a > stock openssh from openssh.com? The modification is minor, to port for FreeBSD. It did work with this modification on the same system. > > You might get some more clues if you run the server in debug mode > (/path/to/sshd -ddde). Unfortunately, this didn't give any new clues. No new debug messages around the failure. I also looked at the server system call trace, and the first major difference is that in successful case one read(2) call returns 16 bytes, and in failed case it returns 0 bytes, which means disconnect. What are the possible client failure points between the server events 'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'? Yuri From benjaminfras at netbens.de Wed Dec 11 22:23:11 2013 From: benjaminfras at netbens.de (=?utf-8?Q?Benjamin_Fras?=) Date: Wed, 11 Dec 2013 12:23:11 +0100 Subject: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: Hi, thanks for your reply. Please find attached the debug trace of the openssh-client: ssh -I /usr/lib/libeToken.so -p 222 10.0.0.41 -vvv OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /usr/local/etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.0.0.41 [10.0.0.41] port 222. debug1: Connection established. debug1: manufacturerID cryptokiVersion 2.20 libraryDescription libraryVersion 8.3 debug1: label manufacturerID model serial <0052787c> flags 0x60d no keys debug3: Incorrect RSA1 identifier debug3: Could not load "/home/benjaminfras/.ssh/id_rsa" as a RSA1 public key debug1: identity file /home/benjaminfras/.ssh/id_rsa type 1 debug1: identity file /home/benjaminfras/.ssh/id_rsa-cert type -1 debug1: identity file /home/benjaminfras/.ssh/id_dsa type -1 debug1: identity file /home/benjaminfras/.ssh/id_dsa-cert type -1 debug1: identity file /home/benjaminfras/.ssh/id_ecdsa type -1 debug1: identity file /home/benjaminfras/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5* debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [10.0.0.41]:222 debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,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-gcm at openssh.com,aes256-gcm at openssh.com,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-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 3a:84:54:ef:16:55:52:27:d5:c4:cf:bd:9d:e8:0a:ac debug3: put_host_port: [10.0.0.41]:222 debug3: put_host_port: [10.0.0.41]:222 debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '[10.0.0.41]:222' is known and matches the ECDSA host key. debug1: Found key in /home/benjaminfras/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/benjaminfras/.ssh/id_rsa (0x85d3b0), debug2: key: /home/benjaminfras/.ssh/id_dsa ((nil)), debug2: key: /home/benjaminfras/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/benjaminfras/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Trying private key: /home/benjaminfras/.ssh/id_dsa debug3: no such identity: /home/benjaminfras/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/benjaminfras/.ssh/id_ecdsa debug3: no such identity: /home/benjaminfras/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). If you have a look at line 8, you'll see that no keys were found. I'm wondering why. I assume that the Safnet driver is not behaving the way as expected from the pkcs11-helper, which is used by openssh-client (please correct me if I'm wrong). Ben -----Urspr?ngliche Nachricht----- > Von:Damien Miller > > Gesendet: Mit 11 Dezember 2013 11:24 > An: Benjamin Fras > > CC: openssh-unix-dev at mindrot.org > Betreff: Re: OpenSSH 6.3p1 Smartcard-Support > > > > On Wed, 11 Dec 2013, Benjamin Fras wrote: > > > Hi there, > > > > has anybody managed to get the eToken Pro Anywhere work with SSH? I'm > > using the latest SafeNetAuthentication drivers available for Ubuntu > > 64bit (8.3) and everything is working just fine except for ssh. I > > can use the eToken for logging in, openvpn, rdestkop, etc. but it > > seems ssh does not recognize the device properly. The command "ssh > > -I /usr/lib/libeToken.so.8 user at hostname" is accessing the eToken > > somehow, as indicated by the blinking led. But it doesn't ask for > > a pin and thus the connection is aborted due to "no authentication > > methods available". > > You'll need to post at least a debug trace if you want help. > > -d > > From mfriedl at gmail.com Wed Dec 11 22:48:25 2013 From: mfriedl at gmail.com (Markus Friedl) Date: Wed, 11 Dec 2013 12:48:25 +0100 Subject: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: <4062C778-DB8E-492A-975A-C826C8B30C65@gmail.com> ssh(1) cannot find the public keys via PKCS#11. please try the latest snapshot. Am 11.12.2013 um 12:23 schrieb Benjamin Fras : > Hi, > > thanks for your reply. Please find attached the debug trace of the openssh-client: > > ssh -I /usr/lib/libeToken.so -p 222 10.0.0.41 -vvv > > OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012 > debug1: Reading configuration data /usr/local/etc/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 10.0.0.41 [10.0.0.41] port 222. > debug1: Connection established. > debug1: manufacturerID cryptokiVersion 2.20 libraryDescription libraryVersion 8.3 > debug1: label manufacturerID model serial <0052787c> flags 0x60d > no keys > debug3: Incorrect RSA1 identifier > debug3: Could not load "/home/benjaminfras/.ssh/id_rsa" as a RSA1 public key > debug1: identity file /home/benjaminfras/.ssh/id_rsa type 1 > debug1: identity file /home/benjaminfras/.ssh/id_rsa-cert type -1 > debug1: identity file /home/benjaminfras/.ssh/id_dsa type -1 > debug1: identity file /home/benjaminfras/.ssh/id_dsa-cert type -1 > debug1: identity file /home/benjaminfras/.ssh/id_ecdsa type -1 > debug1: identity file /home/benjaminfras/.ssh/id_ecdsa-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.4 > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1 > debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5* > debug2: fd 3 setting O_NONBLOCK > debug3: put_host_port: [10.0.0.41]:222 > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,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-gcm at openssh.com,aes256-gcm at openssh.com,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-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 > 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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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_setup: found hmac-md5 > debug1: kex: server->client aes128-ctr hmac-md5 none > debug2: mac_setup: found hmac-md5 > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: ECDSA 3a:84:54:ef:16:55:52:27:d5:c4:cf:bd:9d:e8:0a:ac > debug3: put_host_port: [10.0.0.41]:222 > debug3: put_host_port: [10.0.0.41]:222 > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '[10.0.0.41]:222' is known and matches the ECDSA host key. > debug1: Found key in /home/benjaminfras/.ssh/known_hosts:1 > debug1: ssh_ecdsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/benjaminfras/.ssh/id_rsa (0x85d3b0), > debug2: key: /home/benjaminfras/.ssh/id_dsa ((nil)), > debug2: key: /home/benjaminfras/.ssh/id_ecdsa ((nil)), > debug1: Authentications that can continue: publickey > debug3: start over, passed a different list publickey > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /home/benjaminfras/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey > debug1: Trying private key: /home/benjaminfras/.ssh/id_dsa > debug3: no such identity: /home/benjaminfras/.ssh/id_dsa: No such file or directory > debug1: Trying private key: /home/benjaminfras/.ssh/id_ecdsa > debug3: no such identity: /home/benjaminfras/.ssh/id_ecdsa: No such file or directory > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey). > > If you have a look at line 8, you'll see that no keys were found. I'm wondering why. I assume that the Safnet driver is not behaving the way as expected from the pkcs11-helper, which is used by openssh-client (please correct me if I'm wrong). > > Ben > > > > -----Urspr?ngliche Nachricht----- >> Von:Damien Miller > >> Gesendet: Mit 11 Dezember 2013 11:24 >> An: Benjamin Fras > >> CC: openssh-unix-dev at mindrot.org >> Betreff: Re: OpenSSH 6.3p1 Smartcard-Support >> >> >> >> On Wed, 11 Dec 2013, Benjamin Fras wrote: >> >>> Hi there, >>> >>> has anybody managed to get the eToken Pro Anywhere work with SSH? I'm >>> using the latest SafeNetAuthentication drivers available for Ubuntu >>> 64bit (8.3) and everything is working just fine except for ssh. I >>> can use the eToken for logging in, openvpn, rdestkop, etc. but it >>> seems ssh does not recognize the device properly. The command "ssh >>> -I /usr/lib/libeToken.so.8 user at hostname" is accessing the eToken >>> somehow, as indicated by the blinking led. But it doesn't ask for >>> a pin and thus the connection is aborted due to "no authentication >>> methods available". >> >> You'll need to post at least a debug trace if you want help. >> >> -d >> >> > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Wed Dec 11 22:48:39 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Dec 2013 22:48:39 +1100 (EST) Subject: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: On Wed, 11 Dec 2013, Benjamin Fras wrote: > > Hi, > thanks for your reply. Please find attached the debug trace of the openssh-c > lient: > ssh -I /usr/lib/libeToken.so -p 222 10.0.0.41 -vvv > OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012 > debug1: Reading configuration data /usr/local/etc/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 10.0.0.41 [10.0.0.41] port 222. > debug1: Connection established. > debug1: manufacturerID cryptokiVersion 2.20 libraryDescripti > on libraryVersion 8.3 > debug1: label manufacturerID model serial > <0052787c> flags 0x60d > no keys ^^^^ The PKCS#11 library is being loaded and initialised, but isn't returning any keys to OpenSSH. Can you use something like opensc's pkcs11-tool to list the objects on your card? I.e. pkcs11-tool --module /path/to/pkcs11.so -O -d From dtucker at zip.com.au Thu Dec 12 00:57:46 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 12 Dec 2013 00:57:46 +1100 Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? In-Reply-To: <52A849B6.8020505@rawbw.com> References: <52A83023.5000307@rawbw.com> <52A849B6.8020505@rawbw.com> Message-ID: On Wed, Dec 11, 2013 at 10:17 PM, Yuri wrote: > On 12/11/2013 02:09, Darren Tucker wrote: >> >> That's a modified ssh server. Can you reproduce the problem with a >> stock openssh from openssh.com? > > The modification is minor, to port for FreeBSD. It did work with this > modification on the same system. Please post the debug output from the stock openssh client and server. >> You might get some more clues if you run the server in debug mode >> (/path/to/sshd -ddde). > > Unfortunately, this didn't give any new clues. No new debug messages around > the failure. > > I also looked at the server system call trace, and the first major > difference is that in successful case one read(2) call returns 16 bytes, and > in failed case it returns 0 bytes, which means disconnect. > > What are the possible client failure points between the server events > 'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'? tough to say without seeing the server-side debug output. -- 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 benjaminfras at netbens.de Thu Dec 12 01:20:27 2013 From: benjaminfras at netbens.de (=?utf-8?Q?Benjamin_Fras?=) Date: Wed, 11 Dec 2013 15:20:27 +0100 Subject: AW: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: Hi, This is the output of the pkcs11-tool using the safenet-lib pkcs11-tool --module /usr/lib/libeToken.so -O Using slot 0 with a present token (0x0) Certificate Object, type = X.509 cert label: 411ef289-88cf-4f38-89b1-5e8691f6cb8a ID: 1f67fd84c675af27 Certificate Object, type = X.509 cert label: {E670E946-633C-4956-83B0-5EB67A3A5EAE} ID: e93a991dca5b2939 -----Urspr?ngliche Nachricht----- > Von:Damien Miller > > Gesendet: Mit 11 Dezember 2013 12:48 > An: Benjamin Fras > > CC: openssh-unix-dev at mindrot.org > Betreff: Re: AW: OpenSSH 6.3p1 Smartcard-Support > > On Wed, 11 Dec 2013, Benjamin Fras wrote: > > > > > Hi, > > thanks for your reply. Please find attached the debug trace of the openssh-c > > lient: > > ssh -I /usr/lib/libeToken.so -p 222 10.0.0.41 -vvv > > OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012 > > debug1: Reading configuration data /usr/local/etc/ssh_config > > debug2: ssh_connect: needpriv 0 > > debug1: Connecting to 10.0.0.41 [10.0.0.41] port 222. > > debug1: Connection established. > > debug1: manufacturerID cryptokiVersion 2.20 libraryDescripti > > on libraryVersion 8.3 > > debug1: label manufacturerID model serial > > <0052787c> flags 0x60d > > no keys > > ???? The PKCS#11 library is being loaded and initialised, but isn't > returning any keys to OpenSSH. > > Can you use something like opensc's pkcs11-tool to list the objects > on your card? I.e. pkcs11-tool --module /path/to/pkcs11.so -O > > -d > > From benjaminfras at netbens.de Thu Dec 12 01:49:47 2013 From: benjaminfras at netbens.de (=?utf-8?Q?Benjamin_Fras?=) Date: Wed, 11 Dec 2013 15:49:47 +0100 Subject: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: <4062C778-DB8E-492A-975A-C826C8B30C65@gmail.com> References: Message-ID: Hi, I've downloaded the latest snapshot and now it works like a charm :-))! Thank you guys, you are great! You made my day. Ben -----Urspr?ngliche Nachricht----- > Von:Markus Friedl > > Gesendet: Mit 11 Dezember 2013 12:47 > An: Benjamin Fras > > CC: Damien Miller >; openssh-unix-dev at mindrot.org > Betreff: Re: OpenSSH 6.3p1 Smartcard-Support > > ssh(1) cannot find the public keys via PKCS#11. > please try the latest snapshot. > > > Am 11.12.2013 um 12:23 schrieb Benjamin Fras >: > > > Hi, > > > > thanks for your reply. Please find attached the debug trace of the openssh-client: > > > > ssh -I /usr/lib/libeToken.so -p 222 10.0.0.41 -vvv > > > > OpenSSH_6.4, OpenSSL 1.0.1c 10 May 2012 > > debug1: Reading configuration data /usr/local/etc/ssh_config > > debug2: ssh_connect: needpriv 0 > > debug1: Connecting to 10.0.0.41 [10.0.0.41] port 222. > > debug1: Connection established. > > debug1: manufacturerID cryptokiVersion 2.20 libraryDescription libraryVersion 8.3 > > debug1: label manufacturerID model serial <0052787c> flags 0x60d > > no keys > > debug3: Incorrect RSA1 identifier > > debug3: Could not load "/home/benjaminfras/.ssh/id_rsa" as a RSA1 public key > > debug1: identity file /home/benjaminfras/.ssh/id_rsa type 1 > > debug1: identity file /home/benjaminfras/.ssh/id_rsa-cert type -1 > > debug1: identity file /home/benjaminfras/.ssh/id_dsa type -1 > > debug1: identity file /home/benjaminfras/.ssh/id_dsa-cert type -1 > > debug1: identity file /home/benjaminfras/.ssh/id_ecdsa type -1 > > debug1: identity file /home/benjaminfras/.ssh/id_ecdsa-cert type -1 > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_6.4 > > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1 > > debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5* > > debug2: fd 3 setting O_NONBLOCK > > debug3: put_host_port: [10.0.0.41]:222 > > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > > debug3: load_hostkeys: loaded 1 keys > > debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com ,ecdsa-sha2-nistp384-cert-v01 at openssh.com ,ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > > debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com ,ecdsa-sha2-nistp384-cert-v01 at openssh.com ,ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01 at openssh.com ,ssh-dss-cert-v01 at openssh.com ,ssh-rsa-cert-v00 at openssh.com ,ssh-dss-cert-v00 at openssh.com ,ssh-rsa,ssh-dss > > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com ,aes256-gcm at openssh.com ,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-gcm at openssh.com ,aes256-gcm at openssh.com ,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-etm at openssh.com ,hmac-sha1-etm at openssh.com ,umac-64-etm at openssh.com ,umac-128-etm at openssh.com ,hmac-sha2-256-etm at openssh.com ,hmac-sha2-512-etm at openssh.com ,hmac-ripemd160-etm at openssh.com ,hmac-sha1-96-etm at openssh.com ,hmac-md5-96-etm at openssh.com ,hmac-md5,hmac-sha1,umac-64 at openssh.com ,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com ,hmac-sha1-etm at openssh.com ,umac-64-etm at openssh.com ,umac-128-etm at openssh.com ,hmac-sha2-256-etm at openssh.com ,hmac-sha2-512-etm at openssh.com ,hmac-ripemd160-etm at openssh.com ,hmac-sha1-96-etm at openssh.com ,hmac-md5-96-etm at openssh.com ,hmac-md5,hmac-sha1,umac-64 at openssh.com ,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: none,zlib at openssh.com ,zlib > > debug2: kex_parse_kexinit: none,zlib at openssh.com ,zlib > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: first_kex_follows 0 > > debug2: kex_parse_kexinit: reserved 0 > > debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 > > 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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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_setup: found hmac-md5 > > debug1: kex: server->client aes128-ctr hmac-md5 none > > debug2: mac_setup: found hmac-md5 > > debug1: kex: client->server aes128-ctr hmac-md5 none > > debug1: sending SSH2_MSG_KEX_ECDH_INIT > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > debug1: Server host key: ECDSA 3a:84:54:ef:16:55:52:27:d5:c4:cf:bd:9d:e8:0a:ac > > debug3: put_host_port: [10.0.0.41]:222 > > debug3: put_host_port: [10.0.0.41]:222 > > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > > debug3: load_hostkeys: loaded 1 keys > > debug3: load_hostkeys: loading entries for host "[10.0.0.41]:222" from file "/home/benjaminfras/.ssh/known_hosts" > > debug3: load_hostkeys: found key type ECDSA in file /home/benjaminfras/.ssh/known_hosts:1 > > debug3: load_hostkeys: loaded 1 keys > > debug1: Host '[10.0.0.41]:222' is known and matches the ECDSA host key. > > debug1: Found key in /home/benjaminfras/.ssh/known_hosts:1 > > debug1: ssh_ecdsa_verify: signature correct > > debug2: kex_derive_keys > > debug2: set_newkeys: mode 1 > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug2: set_newkeys: mode 0 > > debug1: SSH2_MSG_NEWKEYS received > > debug1: Roaming not allowed by server > > debug1: SSH2_MSG_SERVICE_REQUEST sent > > debug2: service_accept: ssh-userauth > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug2: key: /home/benjaminfras/.ssh/id_rsa (0x85d3b0), > > debug2: key: /home/benjaminfras/.ssh/id_dsa ((nil)), > > debug2: key: /home/benjaminfras/.ssh/id_ecdsa ((nil)), > > debug1: Authentications that can continue: publickey > > debug3: start over, passed a different list publickey > > debug3: preferred publickey,keyboard-interactive,password > > debug3: authmethod_lookup publickey > > debug3: remaining preferred: keyboard-interactive,password > > debug3: authmethod_is_enabled publickey > > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /home/benjaminfras/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: publickey > > debug1: Trying private key: /home/benjaminfras/.ssh/id_dsa > > debug3: no such identity: /home/benjaminfras/.ssh/id_dsa: No such file or directory > > debug1: Trying private key: /home/benjaminfras/.ssh/id_ecdsa > > debug3: no such identity: /home/benjaminfras/.ssh/id_ecdsa: No such file or directory > > debug2: we did not send a packet, disable method > > debug1: No more authentication methods to try. > > Permission denied (publickey). > > > > If you have a look at line 8, you'll see that no keys were found. I'm wondering why. I assume that the Safnet driver is not behaving the way as expected from the pkcs11-helper, which is used by openssh-client (please correct me if I'm wrong). > > > > Ben > > > > > > > > -----Urspr?ngliche Nachricht----- > >> Von:Damien Miller > > > >> Gesendet: Mit 11 Dezember 2013 11:24 > >> An: Benjamin Fras > > > >> CC: openssh-unix-dev at mindrot.org > > >> Betreff: Re: OpenSSH 6.3p1 Smartcard-Support > >> > >> > >> > >> On Wed, 11 Dec 2013, Benjamin Fras wrote: > >> > >>> Hi there, > >>> > >>> has anybody managed to get the eToken Pro Anywhere work with SSH? I'm > >>> using the latest SafeNetAuthentication drivers available for Ubuntu > >>> 64bit (8.3) and everything is working just fine except for ssh. I > >>> can use the eToken for logging in, openvpn, rdestkop, etc. but it > >>> seems ssh does not recognize the device properly. The command "ssh > >>> -I /usr/lib/libeToken.so.8 user at hostname" is accessing the eToken > >>> somehow, as indicated by the blinking led. But it doesn't ask for > >>> a pin and thus the connection is aborted due to "no authentication > >>> methods available". > >> > >> You'll need to post at least a debug trace if you want help. > >> > >> -d > >> > >> > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From yuri at rawbw.com Thu Dec 12 06:35:21 2013 From: yuri at rawbw.com (Yuri) Date: Wed, 11 Dec 2013 11:35:21 -0800 Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? In-Reply-To: References: <52A83023.5000307@rawbw.com> <52A849B6.8020505@rawbw.com> Message-ID: <52A8BE79.3080201@rawbw.com> On 12/11/2013 05:57, Darren Tucker wrote: >> >What are the possible client failure points between the server events >> >'expecting SSH2_MSG_NEWKEYS' and 'SSH2_MSG_NEWKEYS received'? > tough to say without seeing the server-side debug output. I think I figured out the cause. Fresh ssh client always asks this: The authenticity of host '[server.host.name]:NNN ([server-host-ip]:NNN)' can't be established. ECDSA key fingerprint is NN:NN:NN.... Are you sure you want to continue connecting (yes/no)? I think this "yes" has never been entered for this server host on client. So, as I understand, in my case the server can do absolutely nothing, and it requires the manual interruption on the client to hit "yes". Or those options should be added on the client: -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" Yuri From djm at mindrot.org Thu Dec 12 08:53:52 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Dec 2013 08:53:52 +1100 (EST) Subject: AW: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: On Wed, 11 Dec 2013, Benjamin Fras wrote: > > Hi, > This is the output of the pkcs11-tool using the safenet-lib > pkcs11-tool --module /usr/lib/libeToken.so -O > Using slot 0 with a present token (0x0) > Certificate Object, type = X.509 cert > label: 411ef289-88cf-4f38-89b1-5e8691f6cb8a > ID: 1f67fd84c675af27 > Certificate Object, type = X.509 cert > label: {E670E946-633C-4956-83B0-5EB67A3A5EAE} > ID: e93a991dca5b2939 This is the problem - the released versions only handle plain keys. E.g. [djm at demiurge ~]$ pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O Using slot 2 with a present token (0x5) Public Key Object; RSA 2048 bits label: Private Key ID: 71c719db35ffd0f8087710e57722a3d82f630e58 Usage: encrypt, verify, wrap Certificate Object, type = X.509 cert label: Certificate ID: 71c719db35ffd0f8087710e57722a3d82f630e58 Markus added support for extracting a public key from a certificate only recently. -d From alon.barlev at gmail.com Thu Dec 12 09:01:00 2013 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 12 Dec 2013 00:01:00 +0200 Subject: AW: AW: OpenSSH 6.3p1 Smartcard-Support In-Reply-To: References: Message-ID: On Wed, Dec 11, 2013 at 11:53 PM, Damien Miller wrote: > On Wed, 11 Dec 2013, Benjamin Fras wrote: > >> >> Hi, >> This is the output of the pkcs11-tool using the safenet-lib >> pkcs11-tool --module /usr/lib/libeToken.so -O >> Using slot 0 with a present token (0x0) >> Certificate Object, type = X.509 cert >> label: 411ef289-88cf-4f38-89b1-5e8691f6cb8a >> ID: 1f67fd84c675af27 >> Certificate Object, type = X.509 cert >> label: {E670E946-633C-4956-83B0-5EB67A3A5EAE} >> ID: e93a991dca5b2939 > > This is the problem - the released versions only handle plain keys. E.g. > > [djm at demiurge ~]$ pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -O > Using slot 2 with a present token (0x5) > Public Key Object; RSA 2048 bits > label: Private Key > ID: 71c719db35ffd0f8087710e57722a3d82f630e58 > Usage: encrypt, verify, wrap > Certificate Object, type = X.509 cert > label: Certificate > ID: 71c719db35ffd0f8087710e57722a3d82f630e58 > > Markus added support for extracting a public key from a certificate only > recently. This was supported long ago in the external patch[1] along with other required functionality. I hope that in time (10 years or so) we match the functionality. But it is good we are going at the right direction. Regards, Alon Bar-Lev [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1371 > > -d > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Thu Dec 12 09:06:43 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Dec 2013 09:06:43 +1100 (EST) Subject: Why ssh client breaks connection in expecting SSH2_MSG_NEWKEYS state? In-Reply-To: <52A849B6.8020505@rawbw.com> References: <52A83023.5000307@rawbw.com> <52A849B6.8020505@rawbw.com> Message-ID: On Wed, 11 Dec 2013, Yuri wrote: > On 12/11/2013 02:09, Darren Tucker wrote: > > That's a modified ssh server. Can you reproduce the problem with a > > stock openssh from openssh.com? > > The modification is minor, to port for FreeBSD. It did work with this > modification on the same system. No, it isn't: > debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515 The HPN patch is not a minor modification. -d From jmales at gmail.com Fri Dec 13 03:34:35 2013 From: jmales at gmail.com (J's Mail) Date: Thu, 12 Dec 2013 08:34:35 -0800 Subject: submission: sshd_config documentation clarification Message-ID: The man 5 sshd_config fails to clarify what happens when multiple qualifying Match blocks specify the same configuration option. This patch updates the man page to do so. I tested the behaviour and described what was empirically observed. I can only assume this is the desired behaviour. This is a first attempt. If format or something else is off, let me know; I'll be happy to adjust. ---- Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. If multiple Match blocks are satisfied, and a keyword is specified multiple times, the first Match block instance of the keyword is honored. -------------- next part -------------- --- sshd_config.5 2013-02-11 20:02:08.000000000 -0800 +++ sshd_config.5.jlm 2013-12-12 08:13:42.000000000 -0800 @@ -731,7 +731,12 @@ line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another .Cm Match -line or the end of the file. +line or the end of the file. If multiple +.Cm Match +blocks are satisfied, and a keyword is specified multiple times, the +first +.Cm Match +block instance of the keyword is honored. .Pp The arguments to .Cm Match From loganaden at gmail.com Fri Dec 13 03:42:09 2013 From: loganaden at gmail.com (Loganaden Velvindron) Date: Thu, 12 Dec 2013 20:42:09 +0400 Subject: submission: sshd_config documentation clarification In-Reply-To: References: Message-ID: please open a ticket here as well: https://bugzilla.mindrot.org/ On Thu, Dec 12, 2013 at 8:34 PM, J's Mail wrote: > The man 5 sshd_config fails to clarify what happens when multiple > qualifying Match blocks specify the same configuration option. This > patch updates the man page to do so. > > I tested the behaviour and described what was empirically observed. I > can only assume this is the desired behaviour. > > This is a first attempt. If format or something else is off, let me > know; I'll be happy to adjust. > > ---- > Match > Introduces a conditional block. If all of the criteria on the Match > line are satisfied, the keywords on the following lines override those > set in the global section of the config file, until either another > Match line or the end of the file. If multiple Match blocks are > satisfied, and a keyword is specified multiple times, the first Match > block instance of the keyword is honored. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From jmales at gmail.com Fri Dec 13 03:50:39 2013 From: jmales at gmail.com (J's Mail) Date: Thu, 12 Dec 2013 08:50:39 -0800 Subject: submission: sshd_config documentation clarification In-Reply-To: References: Message-ID: Thanks. Done. https://bugzilla.mindrot.org/show_bug.cgi?id=2184 On Thu, Dec 12, 2013 at 8:42 AM, Loganaden Velvindron wrote: > please open a ticket here as well: > > https://bugzilla.mindrot.org/ > > > On Thu, Dec 12, 2013 at 8:34 PM, J's Mail wrote: >> The man 5 sshd_config fails to clarify what happens when multiple >> qualifying Match blocks specify the same configuration option. This >> patch updates the man page to do so. >> >> I tested the behaviour and described what was empirically observed. I >> can only assume this is the desired behaviour. >> >> This is a first attempt. If format or something else is off, let me >> know; I'll be happy to adjust. >> >> ---- >> Match >> Introduces a conditional block. If all of the criteria on the Match >> line are satisfied, the keywords on the following lines override those >> set in the global section of the config file, until either another >> Match line or the end of the file. If multiple Match blocks are >> satisfied, and a keyword is specified multiple times, the first Match >> block instance of the keyword is honored. >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > > -- > This message is strictly personal and the opinions expressed do not > represent those of my employers, either past or present. From djm at mindrot.org Fri Dec 13 13:56:33 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 13 Dec 2013 13:56:33 +1100 (EST) Subject: PGP key changing Message-ID: Hi, I'm rotating my PGP keys, so this is a forewarning that the key used to sign the next release of portable OpenSSH will be different to the one I've used in the past. Hopefully the gnupg incantations that I recited have resulted in a new key that is correctly cross-signed by my old one so there should be a trust path across the rollover. The new key is available from the key servers and below. It will also show up on the https-hosted list archive too: http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-December/thread.html -d PS. I recommend Apache's key rotation guidelines as a good procedure for rolling keys: http://www.apache.org/dev/key-transition.html PPS. Johnny still can't encrypt -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (OpenBSD) mQGiBDqa5pwRBADJSEyXXsgXiyytN93prDPTPmrueRP9lQQfgaQvCvqK0bN0AF1Z Vxxk9wlSXQp3+Qw5+qqsN5ovzsn39r9pqGslfCqQn9ACTmsn42+VCyW4hdwUGSBS 5myh65ZJTK1ufWCZFssxQ0EiALagu4DlH6Z2O7tFDnJNagF55vlnK0uMQwCg/8RU QYDmisEHjkarAapPaupxjhkD/j9riCVasWPYJwAuhiQWAKxGRwp/ZyTaWCSERUBR 4Dg9QxpuwHKIT8BeDA3hJa/9Yxu5jec2NVKbtVSZvRkgUfRNOkrcH2eiY8Iz6est J64dGWuGMKQW0GEqW+OXpRTTPJZ0mgPmU16qDzLPdx6F3BAk2LG+TTwlKUPuGqOt 6u2EA/4+1CBYZ8mXq9GJnLRBPAoYwSJJzbQnMm9Jat/yg9N6nigSIiFyG8ixh167 gGGKfzvpjY7DeJzDI0Cub+tRova8gFg+T15AcPMST5v7v6O/ug9aYWERZ0zjUhRH ybtYLYhUUbdYM29PwGBNfZhGIOYwfFE9UpPS5LeXHs28oVLlH4jcBCARAgCcBQJS ppQ+lR0BVGhpcyBrZXkgaGFzIGJlZW4gc3VwZXJzZWRlZCBieSBrZXkgSUQgNkQ5 MjBEMzAKS2V5IGZpbmdlcnByaW50ID0gNTlDMiAxMThFIEQyMDYgRDkyNyBFNjY3 ICBFQkUzIEQzRTUgRjU2QiA2RDkyIDBEMzAKUGxlYXNlIHVwZGF0ZSB0byB0aGlz IG5ldyBrZXkuAAoJEM6OywOG/5xIWdMAoJZA/6ls+J6YIpVDFHkb4/8fl0w4AJ90 K3I7hssc7QuWHfPlq3EozRtjIbQuRGFtaWVuIE1pbGxlciAoUGVyc29uYWwgS2V5 KSA8ZGptQG1pbmRyb3Qub3JnPohXBBMRAgAXBQI6muacBQsHCgMEAxUDAgMWAgEC F4AACgkQzo7LA4b/nEiDMgCZAUzKq241h5GTJxC0guS6ht9i9ZsAoL/oXCmFsofA RehZF6AakIdasvS9iEYEExECAAYFAj77h64ACgkQmD+U6HbiLS3r4ACfclqiFP6E TBkTbjqC328yXlT2rlEAnR6Wv3SNayY4jOgfxCMxi61S2CkAiQGsBBABAgAGBQJS ppEIAAoJENPl9Wttkg0wMMsMf0tC6QkZnCkTiEVSar2Bd0gJWRCZOGgWwYnXVXif 5UaQhRgfXyXDxADWi76UYl4v8UFrH9yODXhZM0hoNbt6T98stHmw3dIvrYfhRgQ0 83p/N7II3i1iDJDUZ9PA8n4c5BWXirOUXPxtp23WgsEqG5DaN3CGo99YZO8aB3AH hWd8xvGGDOKOMpAPQekgG/CZw3pcdaSOsZvOEOnbk/VuI2DVjTu/hX0PmRKkfeVf aafi6bcDkm8Vs7Sw4TIrNmGJTKIDhwXSrFlDfs/CmZJUxzP/S7W+dZ4kvESDSWia wmxQFMIxRqgHeLiRHYXCL5Fg+WYFv+EMj/ta5PVot86/iWfrj0MRKZFCpRfDjqTv t0G0ziOW9kTFK8TpxBacJR7n4whM6SNf6L9onHn7xqx2r0J8TLcua9hTvapuNPdL y1cxAKMZO8q10AMGkYd03qLlHxtgKXBeWkV/UYAc1zArv4JFdWTraLbIHmi8jpvE NM3qcNWuNVyiTi4Kxum+CFd8V7b4X/6yBLRD/U6/dMUy4Li5Ag0EOprm1BAIAPP9 ecJzKV72GbGDKe2vfllAkrH2Dp+0HDXvwlLAzc7sk04anf3wSHhD2uQSnk0fWpV5 wb3ncW551P0gBeqvymOnm12oxgJxorL5onRLDXNUPZU5jeHtLJ9TbmlxiIcRrWCt 8o9WhabncjBYZVW2q4Xl2KYB7vn4PRpfJUI6/QTP3CAlHofr2Wnj9wPYbI1oZqvB j0cu8cW9c41jaqb8ZXk6PI5Q7jWCZDinJdCH6ChwUUeszQDO94izCA2knTE1Zdfy JcayvdgK+qbsmghT0krENX73pvEMt9N0qmgtgpvrxZ22YDKWyKjn6Jl9a105v9em TZjHkt1p3L3/6febpy8ABREIAKu+hVJt3QxHQVZf5sFnQ2NJw0GjeQ9JIKdDqNEe iSTPnmv4wd7t2rEInema7tpE6XZ+C6DrChv7v6pd8qR79N1PrC4JvgJ0VLq0+A+t 9hX6LCrY0H8Fq148aDtnpQAtpQtDSbzcMIRUsk2eN6YR0ii5KF6WKQAA7tAMoyvu 8CMfyfTPAynBExee8IzrNiVL2LWQ6bwtUBOTRbKKGlAZJpO6R0+MqUbuwrAy7bSy wr0MZWk+C6VNnusepeXiO5jwtDaPh081o+gpYbwm4FUKzJ/YPoY1b3s98pBKTMV5 mxtUHhJFCtVNyGAFJijFFVbd8uT/JzdMLkBuHoamPiLNrBSIRgQYEQIABgUCOprm 1AAKCRDOjssDhv+cSB+2AJ0chlQNUBYNFrmyJKLwCiz4iLICAACfTbAY6XVaj9gn 5Fj5zoo3nxOYA8SZAaIEN0f88hEEALFoLiocrbjP/CMKikUkAT2h0U8lTI7Ly6+7 lCKFtqn9FVQ1cbkl8uCv5ON0P7LMNpw4qVJEu+LzIBs4FEJOASNC5KD0iFaF6Pr+ uSgkm6zDWJu5Rhje2ZBYOc1g33VRYjeT/7VIPdVH5giO9c6e/EpbcgTPhSzyYQWB NHb5Bw4zAKDe+OFwg00TAESSyvAx9Tt3k5BPtQP/W68qSvFRV9fid432Zs+5w9kr ffuv65HDPj/Fe2xx7bUlS7MIU2fGzGb+WiY7Msj65xRS5pT3XWkAzQ9X1RXr6xzk 20pzI7fJSirIeM/hRQkEwfMLaV27NsR458tTsvJMIgp2ArQ693zmJ6KhZAjME9rp W3Chmdy+pJ3lBkr1joQEAK6oQ2hsLGX5L84qxvb6PzxQcHXijY/7QzhPtUkGrA09 C94Hf7X5mSwQnndskO2saaUJUESHDS9uPhh3n02OWPdk+xi1SINnCuSVLTCjJoFo 97M8l4uTnECsUHYZgYLFrrciY+kpQB0g64xYVWmyHiSrsrmc8Ycr5ks84wbLoLGs iFEEIBECAAkFAjqaxWgCHQEAEgkQormJ9RG1dI8HZUdQRwABAescAJ9xcRB9sD1R Zc1Sn9PUobsBH7KYmACgpChIU+KlYxkNg+HMILaGdN6UIBC0JURhbWllbiBNaWxs ZXIgPGRtaWxsZXJAaWxvZ2ljLmNvbS5hdT6IXwQTEQIAFwUCOiRbBgULBwoDBAMV AwIDFgIBAheAABIJEKK5ifURtXSPB2VHUEcAAQFOAQCghSGVq6nzI3PMyoZ36E0h ALf6I1MAn3qpCrKTqelKqtbZa9aMmJjeT+WOiEYEEBECAAYFAjgwlv8ACgkQfZ7C dhxDQaxfwwCePG3n5ClFBqIF+LT3yAM27vmrlD8AoKeNYojEanqoFm7Btbo6Q51U Eaf8tB9EYW1pZW4gTWlsbGVyIDxkam1AbWluZHJvdC5vcmc+iF8EExECABcFAjok Wy8FCwcKAwQDFQMCAxYCAQIXgAASCRCiuYn1EbV0jwdlR1BHAAEBv0EAnA/tG5nF eWmEW/CUPUPg3iotn6n8AKCdINUw4zfmaSgGjiPecGlYBo2AIYhGBBARAgAGBQI4 MJcIAAoJEH2ewnYcQ0Gs3TMAnAlm/txIYP8Cup6yHmx2JQwcHGCwAKDFyG6E8a3U Ye9Ud/+D3c00fYNr0LQlRGFtaWVuIE1pbGxlciA8ZG1pbGxlckB2aXRuZXQuY29t LnNnPohfBBMRAgAXBQI6JFsvBQsHCgMEAxUDAgMWAgECF4AAEgkQormJ9RG1dI8H ZUdQRwABAfakAJwM6cxduFeyvOD0EykNFeWtRIhpgQCgyINcD1+2UkQxwawGiyqR Iq549TCIRgQQEQIABgUCODCXCAAKCRB9nsJ2HENBrJ32AJsGatu8d4dBFdLftIt4 +3QpQ+XjFwCcD+AL8rhrss96hjmMVxv9UboaqLm5AQ0EN0f9AhAEAN+bUno4vM9S VWkAKSrhClYWQJts2mSxYgLrCqkvv0V1ISBUyOw7v3SUzzg5t6S0BJxeHr6N6oKJ Ej+a3+WPviT1H5EujU6J7NvZpwlclj5fPt8iWkz21+9PHvq+WVrjd9HPXZfAa+5h 8ya7E0bpk/aklT1JJc7++yTgMQRkxIQHAAMFA/9DHpaZ8q2TVRY2v8Tm6Pzi+K+p sMDtKcitUKhPALhjt+1INFjukDcYBSykfJfvbKHequCgBAcYQNA4layRTZE7s2uh 0eYttmOHolTWzwvCKkbheqOCgt83o2YKT6QKaqztJjJqOxl3AaZKQkvL8ydPRL3x MWwCwdCZLhkJ+0iJrIhJBCgRAgAJBQI6msQRAh0BAAoJEKK5ifURtXSPfhsAn0xK sjiC0ruTcw4XFK6qZJz5V1/2AKCP73w6vJEBtEJXW7VrAvjFkB/c7IhUBBgRAgAM BQI3R/0CBQkCx+oAABIJEKK5ifURtXSPB2VHUEcAAQHypgCfRDHTW4PeMEkKx2/K ClQCn4xWbUwAoLrF3lPHbjmk4Em/PV6wBgk290x7uQENBDokXxUUBADnpW+TNB42 /O1nD4iMtlALMTsA56Ox+70fVi36Xyoz8JO16GtOask4Rdi/epHl2WQJueMmqcnl 4TTxqrhcqmDDsMV/mkMlK9d7h9yk5AGgyjJAuYwAJHGcE5PrRDbAf0rasqmx+fyl TqAn8RBRQDFYE210JxBqalC/lhs+AMuiDwAFFwQAoYYPqxV3LADJ3u0CtvNeqeuC 5uOAQeOp+lnWaEk/OKzqtGTXfn2Eqn0XGjyRx4zuJQBB/tXYEI6asZBL3qHSj7Is aC0HR3e+rEkQ3F9eSIVhvjgTQg+JOmNQyy2ITxOW1E6EGJvJD4VUt8rjC7jYbQ57 TUFEX0C+wScUDNAPP2+ISQQoEQIACQUCOprEFQIdAQAKCRCiuYn1EbV0j9TvAJwN wnAyXdWVA9iq/OkPQ0ropkjLgACgl++zOn2nSIsuNeSt7yH2nZf57KuITgQYEQIA BgUCOiRfFQASCRCiuYn1EbV0jwdlR1BHAAEB15kAnRGzqB9wxPi/ZHhOTgye4+gr xz0YAKCWZueK/xD8yp7vYE7CNCfu6CIe3pkBogQ6mt1BEQQAj4Snp2k7phJXeS9O nec+MpeAAn/lbFQ/fCJtLJWXyk3KjG92PVc6uAnbjlW+qeDPcl9m48QpNprZoOYr pz7rXhplW2EjXHe8o5vYIqnuhJ8V5MV5gj/wFQNJAdPV2HLI5jBW0RWoV6N8aXRM QI8lOiVcQv+tZF/IeKGMY7VsPwcAoM39qozTxF7IRNJcKaBsHMMZOXJ1BACCylZO hvq3LrLrKG9gIj483EJwmWDc6B6TTkpMCJ1fzKjej29a3inCUOOERcoevn7HXjTN vu4nxfuQ0mQdd/uX4ZrTba8iHjIHx9J2Fbu2JZTxJkpjznREaY4m8V28RI1jPJ+K igXu4mFR1rQfo/Tuh8gAd+ph3KK2CLPTbx5e+gP/ZJfngU+Itv44z0EOFeK62F5e zORFsaYDEslMM6jP2D2WQlyU6s7+hcVFHOy6a3ThCG80DsiaroCqh80AnpIou23M gMLtTa1f82pk4XqzfpdFKiAK41lYdCFWoKV6bRqKFau7J6Hn/Fvys2UEVQta3BEN 81d0w9yEGZo8fGYFgqm0LkRhbWllbiBNaWxsZXIgKFBlcnNvbmFsIEtleSkgPGRq bUBtaW5kcm90Lm9yZz6IXwQTEQIAFwUCOprdQQULBwoDBAMVAwIDFgIBAheAABIJ EKgZothpHvjaB2VHUEcAAQFcvQCfUagvlvsWQqJN4HBGTIh8tZW6Mr4AnjEjv5Xe m6y3M+KPPzjDMDZ3tiGXiQGsBBABAgAGBQJSpo20AAoJENPl9Wttkg0wpO8Mf0y4 4KTKxWv7YJPv26AEWhZbACf+DoMomOt9eGG08qmratUVcFh05Z9UCZ/M11qR1Ivb HH26MRWKs7yk9YOk1wJINX7uZrogQkzFVQrmsFxA69IlcX7BaAg4yynnDFMasH4/ YC95IrZG4xmu2HGZ1HADqCzlsbFzbOUGZipf/hNuoihgAdbMv8DFONCo6zhINdn7 yKA3pnhn1YD3XgoZIaQ5Ju7qQd9lL8w22bCju3h8aAWFtbESctOE8pf4cF5zQn6m CeNgbiE65BDkg69+TE2Li8wuZeZdbkF4gmiWcSxojPp4JE++nZFUODnAoKI7g4of Gnk/k5DOx2JAqFY3v+meOcDc7BtZU8RPQCkwc6YtGShr+f1lUkNWp7guem4HXw/Y 4zK4bFcFn5iAjfM6zrWC3DiVerFGvoWcvHnRKmUZLfd2/K9BdlwxFWCHfNHXm3BV hMbopdkwzmdJ35IMUQ6vsLcHpuda60XN4Cx9VEfzVrEpgtjL4+40gxngPoCG0RTR OvmtmBtWo38TXTAWfzq5AQ0EOprdQxAEAKfycj/ga8be0+b00yUlDFkozgvmgTWT RRR2xvSlt8fKqBO3f0mCxiKh17HBkNGuoM6HtNQxYg6L7YqTOoPxWqwj40VTDe9k hI7tqb+4ZRq/33Mh4SjmMHMWglRTkHrZZyquM1ayb3NDmQ/57G0Qh9s3t0+cbUkO yJSf6w1H/9ibAAMGA/9odnrEBD0MvDEaRYXAWfGd4lWgGdC0oL6GqfESgUps0vUB 2IJP1ODfZFugRUAX5htNmhjCzflh8vKDDDVRGicZEL11O3r3drzyJPZlvCUnqgBm u3ZmUY1ZCjwQ8u/XkqDP2fBm9UxZyifY7vrPqanYtGyT7A7cvsgPvejBTsuXqYhO BBgRAgAGBQI6mt1DABIJEKgZothpHvjaB2VHUEcAAQFQxwCeNB/Ncc9JFUnevzVR ywxHe/vfF7QAn2Zgc5m8W0NXYZyoN4cQAmbysDCrmQGdBFKmggUBDICUNqm4cNh7 tdEbwaNhbnwqLiHpILeXT6sddGI0Stz5ofB1uvIHm9kXYG5XUUwlc5ywjIZm2Jeu Kqrd/6wAz5laLagFA6k86EZzzuBE3b5FxSQ4EN4K5XZEJo61xASEF7z1mQCiqoA6 /F407ht7nNoiVE95kOmqJlv4cqbpCw3n8f2VW+mVUH6MYRZVrYAC9NnJWv24rem2 fjgFhNT1/bx44G7H9bVJqL7hMEGa+xYQBI3YT/ulEu9HYmLFVeiZm1gB1eKXW7jS 4ctLl5uPrxayA5DX/qNB2yqgVVlIKFwUm8gGPGPOnsNKo0xBseE7E0F/KeGpaT5a S9yFgPm9A652Jx9felYgb0e9Ipt3lxriPQwgF/cxLGuP/WEbN5fpWFnuV0Viklus uVI2e8GHJGU5bQD5AlzvWu4Sv6oBOcDCabScydY7IxPBk/XBWCF9QDIa2qa32Mc9 dYc8EnJszPeVCHX5hG23omDRmdLGLwH7F+CuBvCxAKCymZtJl5DhRmnhdzRg9d+0 VG4hLF7O06ANABEBAAG0H0RhbWllbiBNaWxsZXIgPGRqbUBtaW5kcm90Lm9yZz6J Ac0EEwECACcCGwMFCQ1H67ECHgECF4AFAlKmjJwECwkIBwYVCgkICwIFFgIDAQAA CgkQ0+X1a22SDTB2TAx9E1ozPJKUGWJPZefqsSr8KsO6Dp3QuPrw2Zwgo2QfeCT+ uzNA5AKCDIAaYEpVbQsvu4sDy8dAW1+HENCxVrMXWG+SH41lcdAdI4io0PGHVQDl 42R5jX3e9pfjYCQALVv5BDXddK6054nyxEmudQ3ICFCYXIcqQbA1nfj3Uk06jGhu M99B2/akbxCoFSiUX9uHDZKNYAGpU7/FCF9xCZF4Kd9Twvyy17jDIg7km3/Q4Jy+ +VP8FyvE5JjBdLRQSBzSG9GCjv9fyKWW7S0bMY4D3SKKt/Jm1XchEMgpRr4eBpgC s3rxO1hXjzqm3te97uy6/q8CuJUtupJsPKc9Wh4+ogUZifC0ta7UrxZp8yZTRvPS UxYrlvDzM32VDLQ3FX6Y2i4VNo48PSJMA+BPUx7DTcZKIXt457zsLD4jF4sRdwOk /QF/GXCkH2GAyKHWCPXIOe+jIXgiuajcqZm9cAWjL3hidSohKfefvKkzsg75mDmj hvAtDncIbmImJNjXIe2PQU4iY9Vq5i0vlaVKgBgKSohGBBARAgAGBQJSpovfAAoJ EM6OywOG/5xInf8An0A7MPrfJIz2e643VEV4AX3dO9+IAJ9MOsQiB4LnqtTcc9NB MHf9VLE46LkBnQRSpoIFAQyA1OdwfpwXKch+O00W1FsQSMcEjahGmo84WTroM/qj Td7Ysld300PMv3wkQn2WdhyTca/EmkW0fVTGSYs7Z3v5SpPf0prYSjmfu8WlXoz6 4ApdXqGHjj9KAeq2OuUtWrwobgiQEzU4Hxlz94X/65BgG5k7OTyE3J6bgRcMwJCg CkwjK85wbbBkGH+Jo9o/Zw9TPczQcE7BmGYkkLNAXbw7omKBOL4Z6w9sXToz9UnQ 0EB9s4TvAbHGKX9y2PEQjZN+wkzR3DavWB7ql8vHZIRmspAsDAJvDT1ofsNtu8MB 8wJcxvZaoZ7j9wULYpnaNYx9xxEhgbB9o1mBcYsdDj3xz5jrgtq/cpdgGC6bg+aw Dc/ylQ1mNglKfY8P9hFIhIANZilnmAlk5GSoWclP/69m+u34KKoHU4Yc3I1pPNcL 6Nyi0bh8mHqe9WedKfod7Y4yM1S20fXaS4vrLIlKgxbsDpWiWrk0ltV03uyC7eqD e3nzzGW/2GLTHj5xsA2+HwGtPom5mmzjvV5PFNpS7a90JQARAQABiQG1BBgBAgAP BQJSpoIFAhsMBQkNR+uxAAoJENPl9Wttkg0wEScMf2QjDWm3XawJxNA8pqqxrFeT Eo+GESznVRTUeprrUFd1GHw33qaAvqLixZ+x8cr+1Gj/fJd5eiIVJfRLYbXlC8su 8JZXngfX0VhuMcUob/FTikfpcoYkRzriUsJEB3/OmjlLjGgnQm5Gz9TV1ityF3bz oHkR8svWEKKKzNoIEPHLU3y7bqSkOrjnY3bZfdVRh618XbjV28NMuoZsV8E4pOuQ oy+3s5IjmIf/mkSiFE3VJwdaPem23UsXatFb/eoC/Ahi0iCd/8ioFwi+oHT2Pnt9 HrzVF6E8gBVO3vKo6UJgDTr9Qt27Nc6eHL0O5j50ins9ob/3DoOC3P5A08zhl+w4 66yGEv5+Es/usUAs/4ng4ksI3DTLK9Ygj70l5oBuMFYd3b5KGVfAIlGc5mwIOIG4 1YLIzZTrGuOuTymjwCdC9cUZJ6R2Cv/Vx0htZ0hqDdyaDO0Io9OG/W2s2T7160tY 9ic4MwBCFemzwFELIBIIHNY/n/wsmxQGkI3Oj86JpOVVgR5lXWR+BrGcBjkSEyg= =s7sa -----END PGP PUBLIC KEY BLOCK----- From dheidler at suse.de Mon Dec 16 20:54:48 2013 From: dheidler at suse.de (Dominik Heidler) Date: Mon, 16 Dec 2013 10:54:48 +0100 Subject: [PATCH] allow entering smartcard pin via pinpad Message-ID: <52AECDE8.3020805@suse.de> The CKF_PROTECTED_AUTHENTICATION_PATH flag (as returned by C_GetTokenInfo) should be used to decide weather to request the PIN via terminal or let the reader fetch the pin from pinpad. https://bugzilla.mindrot.org/show_bug.cgi?id=2185 The patch is attached to the bug report. From RudolfPotucek at smarttech.com Tue Dec 17 14:21:27 2013 From: RudolfPotucek at smarttech.com (Rudolf Potucek) Date: Tue, 17 Dec 2013 03:21:27 +0000 Subject: Puzzled by -R dropping first argument Message-ID: Hi All! I am puzzled. I am using openssh 5.3p1 on RHEL/CentOS but am seeing the same behaviour for osx and debian: ssh -R xxx:yyy:yyy:yyy remotehost Will effectively drop the first (xxx) argument and result in ssh -R 127.0.0.1:yyy:yyy:yyy remotehost ssh -R yyy:yyy:yyy remotehost I had a look at the source code where apparently all 4 values are ready and handed down to the appropriate forwarding request. Yet in the end the first argument gets dropped / replaced? I can see two important uses of -R and would really like to make this work, even if this means I have to patch all my ssh client and server packages: (1) Allowing the reuse of a local port if something is already listening on that port and the client can only be pointed at an IP, not a custom port: ssh -R 127.0.0.2:ppp:127.0.0.1:ppp remotehost which works perfectly in reverse ssh -L 127.0.0.2:ppp:127.0.0.1:ppp remotehost but poses a security risk because now the client would know the server password. (2) Picking an interface in a multihomed system Any suggestions welcome, Rudolf From RudolfPotucek at smarttech.com Tue Dec 17 14:37:16 2013 From: RudolfPotucek at smarttech.com (Rudolf Potucek) Date: Tue, 17 Dec 2013 03:37:16 +0000 Subject: Puzzled by -R dropping first argument In-Reply-To: Message-ID: Ok, nevermind, I am an idiot ? this is "by design" and requires appropriate setting of GatewayPorts=userspecified on the server. From: Rudoef Potucek > Date: Monday, 16 December, 2013 8:22 PM To: "openssh-unix-dev at mindrot.org" > Subject: Puzzled by -R dropping first argument Hi All! I am puzzled. I am using openssh 5.3p1 on RHEL/CentOS but am seeing the same behaviour for osx and debian: ssh -R xxx:yyy:yyy:yyy remotehost Will effectively drop the first (xxx) argument and result in ssh -R 127.0.0.1:yyy:yyy:yyy remotehost ssh -R yyy:yyy:yyy remotehost I had a look at the source code where apparently all 4 values are ready and handed down to the appropriate forwarding request. Yet in the end the first argument gets dropped / replaced? I can see two important uses of -R and would really like to make this work, even if this means I have to patch all my ssh client and server packages: (1) Allowing the reuse of a local port if something is already listening on that port and the client can only be pointed at an IP, not a custom port: ssh -R 127.0.0.2:ppp:127.0.0.1:ppp remotehost which works perfectly in reverse ssh -L 127.0.0.2:ppp:127.0.0.1:ppp remotehost but poses a security risk because now the client would know the server password. (2) Picking an interface in a multihomed system Any suggestions welcome, Rudolf From pcerny at suse.cz Wed Dec 18 00:46:25 2013 From: pcerny at suse.cz (Petr Cerny) Date: Tue, 17 Dec 2013 14:46:25 +0100 Subject: mercurial repository Message-ID: <52B055B1.5030206@suse.cz> Hi, the mercurial repository http://hg.mindrot.org/openssh hasn't been updated since a while now - are there any plans on bringing it back up-to-date again? Is there anything I could do to help with that? Thanks Cheers Petr -- Petr Cerny Mozilla/OpenSSH maintainer for SUSE Linux From keisial at gmail.com Wed Dec 18 07:22:42 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 17 Dec 2013 21:22:42 +0100 Subject: mercurial repository In-Reply-To: <52B055B1.5030206@suse.cz> References: <52B055B1.5030206@suse.cz> Message-ID: <52B0B292.7020002@gmail.com> On 17/12/13 14:46, Petr Cerny wrote: > Hi, > > the mercurial repository http://hg.mindrot.org/openssh hasn't been > updated since a while now - are there any plans on bringing it back > up-to-date again? Is there anything I could do to help with that? > > Thanks > Cheers > Petr See http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031860.html > "hg convert" seems to have stopped working for some reason - it no longer > appears to be recognising changes. I think I'll just pull the hg repository > and replace it with a git one. So I guess the possible help would be fixing whatever problem the current repo seems to have. From djm at mindrot.org Wed Dec 18 13:50:31 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Dec 2013 13:50:31 +1100 (EST) Subject: mercurial repository In-Reply-To: <52B0B292.7020002@gmail.com> References: <52B055B1.5030206@suse.cz> <52B0B292.7020002@gmail.com> Message-ID: I've pulled it down now. I'll replace it with a git repository in the new year when I have some spare time. On Tue, 17 Dec 2013, ?ngel Gonz?lez wrote: > On 17/12/13 14:46, Petr Cerny wrote: > > Hi, > > > > the mercurial repository http://hg.mindrot.org/openssh hasn't been updated > > since a while now - are there any plans on bringing it back up-to-date > > again? Is there anything I could do to help with that? > > > > Thanks > > Cheers > > Petr > > See > http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031860.html > > "hg convert" seems to have stopped working for some reason - it no longer > > appears to be recognising changes. I think I'll just pull the hg repository > > and replace it with a git one. > > So I guess the possible help would be fixing whatever problem the current repo > seems to have. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dkg at fifthhorseman.net Wed Dec 18 13:52:09 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 21:52:09 -0500 Subject: PGP key changing In-Reply-To: References: Message-ID: <871u1azx9i.fsf@alice.fifthhorseman.net> On Thu 2013-12-12 21:56:33 -0500, Damien Miller wrote: > I'm rotating my PGP keys, so this is a forewarning that the key used to > sign the next release of portable OpenSSH will be different to the one > I've used in the past. Thanks for the heads-up, Damien, and thanks for doing this boring maintenance work and announcing it clearly ahead of time. I note that some of the OpenSSH mirrors have DJM-GPG-KEY.asc, which i think is the old one. e.g. http://mirrors.nycbug.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc Maybe you could update the key on the mirrors too when you get a chance. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From djm at mindrot.org Wed Dec 18 14:33:28 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Dec 2013 14:33:28 +1100 (EST) Subject: PGP key changing In-Reply-To: <871u1azx9i.fsf@alice.fifthhorseman.net> References: <871u1azx9i.fsf@alice.fifthhorseman.net> Message-ID: On Tue, 17 Dec 2013, Daniel Kahn Gillmor wrote: > On Thu 2013-12-12 21:56:33 -0500, Damien Miller wrote: > > I'm rotating my PGP keys, so this is a forewarning that the key used to > > sign the next release of portable OpenSSH will be different to the one > > I've used in the past. > > Thanks for the heads-up, Damien, and thanks for doing this boring > maintenance work and announcing it clearly ahead of time. > > I note that some of the OpenSSH mirrors have DJM-GPG-KEY.asc, which i > think is the old one. e.g. > > http://mirrors.nycbug.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc > > Maybe you could update the key on the mirrors too when you get a chance. I was going to leave that one there until I make a release signed with the new key. Otherwise, people who get the key for the first time ahead of the release will see "key superseded" deprecation warnings. -d From djm at mindrot.org Wed Dec 18 14:43:45 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Dec 2013 14:43:45 +1100 (EST) Subject: PGP key changing In-Reply-To: References: <871u1azx9i.fsf@alice.fifthhorseman.net> Message-ID: On Wed, 18 Dec 2013, Damien Miller wrote: > I was going to leave that one there until I make a release signed with > the new key. Otherwise, people who get the key for the first time ahead > of the release will see "key superseded" deprecation warnings. ... for the existing signatures From dkg at fifthhorseman.net Wed Dec 18 14:53:15 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 22:53:15 -0500 Subject: PGP key changing In-Reply-To: References: <871u1azx9i.fsf@alice.fifthhorseman.net> Message-ID: <52B11C2B.7030405@fifthhorseman.net> On 12/17/2013 10:43 PM, Damien Miller wrote: > On Wed, 18 Dec 2013, Damien Miller wrote: > >> I was going to leave that one there until I make a release signed with >> the new key. Otherwise, people who get the key for the first time ahead >> of the release will see "key superseded" deprecation warnings. > > ... for the existing signatures Ah, right. that makes sense. thanks for thinking it through :) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dave at deezee.org Fri Dec 20 00:15:56 2013 From: dave at deezee.org (Dave Saville) Date: Thu, 19 Dec 2013 13:15:56 +0000 (GMT) Subject: Trying to compile for OS/2 Message-ID: <000.f0ba04008cf1b252.044@deezee.org> Hi I hope I have found the right list :-) If not, my apologies and a pointer would be appreciated. I am trying to compile openssh-6.3p1 for OS/2 aka EcomStation. For those unfamiliar OS/2 is a DOSish OS but usually porting *nix apps is pretty straightforward. It is complicated by the fact that our current libc implementation of pipe() is flawed and I have to use socketpair() instead. I think I have found all the places where pipes are allocated and changed to use socketpair. It is further complicated by the fact that we don't have tty support either. :-) There is no /dev tree although /dev/console is supported internally. Having said that it all compiles clean - after the insertion of a few casts here and there :-) Using either ssh or sshd to tunnel works fine - both to each other and to "real" ssh on a linux box. But when it comes to interactive terminal both they, and sftp, fail. ssh -vvvv shardik (which is a *nix box) snip snip debug1: Authentication succeeded (password). Authenticated to shardik ([192.168.0.1]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. tcgetattr: Invalid argument debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug1: tty_make_modes: no fd or tio debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 24576 rmax 32768 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) select: Invalid argument Connection to shardik closed. Transferred: sent 3552, received 1136 bytes, in 0.0 seconds Bytes per second: sent 77217.4, received 24695.6 debug1: Exit status -1 The tcgetattr() error I have not tracked down yet but a Google search suggested that it could be ignored. The select() error is in Clientloop.c/client_wait_until_can_do_something #655 and would appear to be because one of the file descripters, 4, is an OS/2 file handle. I have yet to work out why or where is got allocated. That line of code is executed many times before fd 4 appears when it immediately barfs. I get similar problems with sshd but suspect that when I track down what's wrong with ssh the solution will be the same/similar. It would help of course if I had an understanding of what called what and under what conditions to insert additional debugging statements. I can't help feeling that it is something both obvious and silly. TIA -- Kind regards Dave Saville From pjd at FreeBSD.org Sat Dec 21 00:27:07 2013 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri, 20 Dec 2013 14:27:07 +0100 Subject: sandbox-rlimit and ptrace. Message-ID: <20131220132707.GC1658@garage.freebsd.pl> I was wondering if the following attack would be feasible once I'm able to break into rlimit sandbox. Because sandboxed process that handles unauthenticated session is running as the 'sshd' user I was wondering if this could be used to jump between processes using ptrace(2). For example if I find a bug in the code executed before authentication I could use ptrace(2) to attach to another unprivileged processes running with the same credentials as I am. If I understand correctly this sandbox process is responsible for extracting credentials of the connecting user from the protocol, which means if I attach to a process handling root loggining in with a password I could obtain root's password. Can someone confirm or tell me what am I missing? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From imorgan at nas.nasa.gov Sat Dec 21 06:01:12 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 20 Dec 2013 11:01:12 -0800 Subject: additional compiler hardening flags In-Reply-To: <20130418014100.GA30605@gate.dtucker.net> References: <20130322050815.GA6024@gate.dtucker.net> <20130417230311.GD17666@linux124.nas.nasa.gov> <20130418011613.GA16696@gate.dtucker.net> <20130418014100.GA30605@gate.dtucker.net> Message-ID: <20131220190112.GT10110@linux124.nas.nasa.gov> On Wed, Apr 17, 2013 at 20:41:00 -0500, Darren Tucker wrote: > On Thu, Apr 18, 2013 at 11:16:13AM +1000, Darren Tucker wrote: > > Anyway, we could easily add a configure knob to turn it off should that > > be necessary. > > here's an updated patch without -fPIC, and with a configure knob > (--without-hardening) to turn this off. > Hi, I don't recall seeing these improvements to the build system being committed. Is there any chance of adding them for the next release, or is it too late in the development cycle? -- Iain Morgan From djm at mindrot.org Sat Dec 21 07:54:02 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 21 Dec 2013 07:54:02 +1100 (EST) Subject: sandbox-rlimit and ptrace. In-Reply-To: <20131220132707.GC1658@garage.freebsd.pl> References: <20131220132707.GC1658@garage.freebsd.pl> Message-ID: On Fri, 20 Dec 2013, Pawel Jakub Dawidek wrote: > I was wondering if the following attack would be feasible once I'm able > to break into rlimit sandbox. > > Because sandboxed process that handles unauthenticated session is > running as the 'sshd' user I was wondering if this could be used to jump > between processes using ptrace(2). For example if I find a bug in the > code executed before authentication I could use ptrace(2) to attach to > another unprivileged processes running with the same credentials as I > am. If I understand correctly this sandbox process is responsible for > extracting credentials of the connecting user from the protocol, which > means if I attach to a process handling root loggining in with a > password I could obtain root's password. > > Can someone confirm or tell me what am I missing? It shouldn't be possible because the child process has a setuid in its history and this should deny ptrace of the process by any user but root. -d From pjd at FreeBSD.org Sun Dec 22 12:56:56 2013 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sun, 22 Dec 2013 02:56:56 +0100 Subject: sandbox-rlimit and ptrace. In-Reply-To: References: <20131220132707.GC1658@garage.freebsd.pl> Message-ID: <20131222015656.GB1673@garage.freebsd.pl> On Sat, Dec 21, 2013 at 07:54:02AM +1100, Damien Miller wrote: > On Fri, 20 Dec 2013, Pawel Jakub Dawidek wrote: > > > I was wondering if the following attack would be feasible once I'm able > > to break into rlimit sandbox. > > > > Because sandboxed process that handles unauthenticated session is > > running as the 'sshd' user I was wondering if this could be used to jump > > between processes using ptrace(2). For example if I find a bug in the > > code executed before authentication I could use ptrace(2) to attach to > > another unprivileged processes running with the same credentials as I > > am. If I understand correctly this sandbox process is responsible for > > extracting credentials of the connecting user from the protocol, which > > means if I attach to a process handling root loggining in with a > > password I could obtain root's password. > > > > Can someone confirm or tell me what am I missing? > > It shouldn't be possible because the child process has a setuid in its > history and this should deny ptrace of the process by any user but root. Indeed, thanks. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From mikep at noc.utoronto.ca Tue Dec 24 07:52:14 2013 From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca) Date: Mon, 23 Dec 2013 15:52:14 -0500 (EST) Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails In-Reply-To: References: Message-ID: On Wed, 13 Nov 2013, Loganaden Velvindron wrote: > On Wed, Nov 13, 2013 at 2:05 AM, Darren Tucker wrote: >> On Tue, Nov 12, 2013 at 4:40 PM, wrote: >> >>> Just upgraded to OpenSSH_6.4 with OpenSSL 1.0.1e and libz.so.1.2.8. >>> Now some (but not all) Cisco router logins hang: >>> >>> debug1: sending SSH2_MSG_KEXDH_INIT >>> debug1: expecting SSH2_MSG_KEXDH_REPLY >>> [hangs] >>> >> >> Suggestions in approximate order of likelihood. >> - the additional KexAlgorithms exceed some static buffer in the Cisco. >> Try: >> "KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1" >> - you have some kind of path MTU problem and the extra traffic from the >> additional algorithms pushes you past some packet boundary. Check the >> "send-q" column on client and the equivalent on the server and see if >> they're non-zero and non-decreasing). > > Shouldn't Mike open a ticket at CISCO so that they start fixing the > software on their side as well ? Sorry to have taken so long to get back to you about this - your suggestion about "KexAlgorithms" caused me to test a lot of combinations to find what will work. It turns out the Cisco SSH server only supports a limited set of ciphers (this is documented sort-of by Cisco, and is displayed when you try to force a non-supported cipher). This in turn seems to limit the key exchange mechanisms that will work. Forcing a cipher with '-c' also appears to force something in the Kex for OpenSSH; I can't find anything about Kex in any Cisco docs. I have created a special section of the 'ssh_config' file for those devices with these options, and all seems to be working fine: Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 Thank you for the help! >>> Originally I had 'Cipher blowfish' set in '/etc/ssh/ssh_config', but >>> removing that makes no difference. >> >> That's because Cipher affects only Protocol 1 (which was some time in the >> past the only version at least some Cisco devices spoke). >> >>> However, forcing '-c 3des' does >>> allow it to work (even though '3des' is supposed to be the default): >> >> 3des is the default Cipher Protocol 1. Protocol 2 takes a list (Ciphers) >> and its default is >> >> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, >> aes128-gcm at openssh.com,aes256-gcm at openssh.com, >> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc, >> aes256-cbc,arcfour >> >> the -c option overrides both. >> >> -- >> 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. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Mike -- Mike Peterson Information Security Analyst - Audit E-mail: mikep at noc.utoronto.ca WWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 From dtucker at zip.com.au Tue Dec 24 11:00:40 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Dec 2013 11:00:40 +1100 Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails In-Reply-To: References: Message-ID: On Tue, Dec 24, 2013 at 7:52 AM, wrote: [...] > Sorry to have taken so long to get back to you about this - your suggestion > about "KexAlgorithms" caused me to test a lot of combinations to find what > will work. It turns out the Cisco SSH server only supports a limited set of > ciphers (this is documented sort-of by Cisco, and is displayed when you try > to force a non-supported cipher). > > This in turn seems to limit the key exchange mechanisms that will work. > > Forcing a cipher with '-c' also appears to force something in the Kex for > OpenSSH; I can't find anything about Kex in any Cisco docs. I'm happy you found something that works, but the SSH protocol 2 negotiation should allow it to negotiate a mutually-compatible set of algorithms or to definitively tell you that no such set exists. The fact that it hangs with some settings means there's still a bug in there somewhere. Did you get a response from Cisco? -- 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 parke.nexus at gmail.com Tue Dec 24 11:07:44 2013 From: parke.nexus at gmail.com (Parke) Date: Mon, 23 Dec 2013 16:07:44 -0800 Subject: sftp-server versus internal-sftp Message-ID: Hi, I recently discovered that my ~/.bashrc file was preventing me from using SFTP successfully. I then found documentation of sftp-server and internal-sftp. However, I could not find answers to the following questions in the documentation. 1) What are the advantages of sftp-server over internal-sftp? (I believe Ubuntu and Debian both default to "Subsystem sftp /usr/lib/openssh/sftp-server".) 2) What is the advantage of having the subsystem run sftp-server via the user's shell, instead of just running sftp-server directly? Thanks! -Parke From lukas at stabe.de Tue Dec 24 14:28:56 2013 From: lukas at stabe.de (Lukas Stabe) Date: Tue, 24 Dec 2013 04:28:56 +0100 Subject: ssh-copy-id: Issue with target machine with non-sh shell Message-ID: <4A464A6D-D937-47DE-9A29-AB30AD8A9726@stabe.de> Hi! I have the following issue with ssh-copy-id: The login-shell of the user I am trying to copy my keys to is fish. fish does not behave very sh-y. For example it does not support `command || alternative`, which makes it choke on the following part of the script (lines 273 ff): ssh "$@" " umask 077 ; mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ; if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi? There is a very simple solution to this, which would make the code more robust in general: execute the code on the target machine in a `/bin/sh -c '?` call, like this: ssh "$@? ?/bin/sh -c ' umask 077 ; mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ; if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi?? Please consider adding this to ssh-copy-id :) Best regards, Lukas Stabe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kaz at kylheku.com Wed Dec 25 16:23:08 2013 From: kaz at kylheku.com (Kaz Kylheku) Date: Tue, 24 Dec 2013 21:23:08 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" Message-ID: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> We cannot conclude that just because the source IP address of a connection doesn't have forward and reverse DNS info, that the connection is a break-in attempt. This is a content-free entry that wastes valuable visual space in the auth log: Dec 23 2013 18:51:44 localhost sshd[30321]: reverse mapping checking getaddrinfo for 222.109.250.63.static.addr.dsl4u.ca [63.250.109.222] failed - POSSIBLE BREAK-IN ATTEMPT! That was me, logging in from a smartphone, from a Wi-Fi hotspot. Never mind logging; the software should not even be performing these pointless time and bandwidth wasting lookups. From mouring at offwriting.org Wed Dec 25 19:04:33 2013 From: mouring at offwriting.org (Ben Lindstrom) Date: Wed, 25 Dec 2013 02:04:33 -0600 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> Message-ID: If it bothers you turn it off: UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is ``yes''. - Ben On Dec 24, 2013, at 11:23 PM, Kaz Kylheku wrote: > > > We cannot conclude that just because the source IP address of a > connection doesn't have forward and reverse DNS info, that the > connection is a break-in attempt. This is a content-free entry that > wastes valuable visual space in the auth log: > > Dec 23 2013 18:51:44 localhost sshd[30321]: reverse mapping checking > getaddrinfo for 222.109.250.63.static.addr.dsl4u.ca [63.250.109.222] > failed - POSSIBLE BREAK-IN ATTEMPT! > > That was me, logging in from a smartphone, from a Wi-Fi hotspot. > > Never mind logging; the software should not even be performing these > pointless time and bandwidth wasting lookups. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ashfaqnadim at yahoo.com Fri Dec 27 03:32:32 2013 From: ashfaqnadim at yahoo.com (Ashfaq Nadim) Date: Thu, 26 Dec 2013 08:32:32 -0800 (PST) Subject: To see fullpath instead of realitive path in chrooted sftp Message-ID: <1388075552.9063.YahooMailNeo@web164906.mail.bf1.yahoo.com> Hi In a chrooted sftp syatem i'm trying to log (user file transaction log) full path instead of relative path. (like /home/user1/file/a.txt instead of /file/a.txt). Without chroot sftp it works fine, but in chrooted system i do not get full path, which i need badly. Goggled for it for so long, but no luck. Is there any way? any hint from you will be appreciated. Thnaks Ashfaq From alex at alex.org.uk Fri Dec 27 04:27:49 2013 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 26 Dec 2013 17:27:49 +0000 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> Message-ID: <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: > UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP > address maps back to the very same IP address. The default is ``yes''. I've often wondered why the default for this is 'yes'. -- Alex Bligh From kaz at kylheku.com Fri Dec 27 08:47:10 2013 From: kaz at kylheku.com (Kaz Kylheku) Date: Thu, 26 Dec 2013 13:47:10 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: On 26.12.2013 09:27, Alex Bligh wrote: > On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: > >> UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is ``yes''. > > I've often wondered why the default for this is 'yes'. I don't want to read reference manuals. I want software not to do stupid things by default. This misfeature and its configuration option shouldn't even exist. There isn't any action that the software can take based on this info. (We should never waste resources gathering info that cannot be used to take action.) You cannot reject hosts from making SSH connections just because they have inconsistent DNS. Such checks are sometimes useful in software that has no real security, like SMTP. Rejecting inconsistent DNS hosts is an amazingly reliable rule that will get rid of a large fraction of spam, with virtually no false positives. From dan at doxpara.com Fri Dec 27 09:19:08 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 26 Dec 2013 14:19:08 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: The deal is that IP addresses are useless, host names are useful , but host name spoofing is actually a real thing that real attackers do. So, either you don't log, you log hacker controlled data, or you UseDNS. OpenSSH, optimizing for security, chooses the last of these options. On Thursday, December 26, 2013, Kaz Kylheku wrote: > > > On 26.12.2013 09:27, Alex Bligh wrote: > > > On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: > > > >> UseDNS Specifies whether sshd(8) should look up the remote host name > and check that the resolved host name for the remote IP address maps back > to the very same IP address. The default is ``yes''. > > > > I've often wondered why the default for this is 'yes'. > > I don't want to read reference manuals. I want software not to do stupid > things by default. This misfeature and its configuration option > shouldn't even exist. > > There isn't any action that the software can take based on this info. > (We should never waste resources gathering info that cannot be used to > take action.) > > You cannot reject hosts from making SSH connections just because they > have inconsistent DNS. > > Such checks are sometimes useful in software that has no real security, > like SMTP. Rejecting inconsistent DNS hosts is an amazingly reliable > rule that will get rid of a large fraction of spam, with virtually no > false positives. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From amarendra.godbole at gmail.com Fri Dec 27 11:02:48 2013 From: amarendra.godbole at gmail.com (ag@gmail) Date: Thu, 26 Dec 2013 16:02:48 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: <6542005F-5864-4D5B-9849-AEFA40FFE11A@gmail.com> If OpenSSH takes no action, this entry does seem pretty useless for the functionality. I don't think it adds any real life security improvement, but adds too much noise which will be ignored anyways. It may be useful to other log-analyzer software trying make sense, but again the number of false positives render useless any meaningful interpretation of these log entries as well. I can't think if a use case for this logging to be enabled by default, if at all it needs to be there, but I may have missed the obvious (which hasn't been yet discussed in this thread). Thanks. -coderaptor -- sent via 100% recycled electrons from my mobile command center. > On Dec 26, 2013, at 2:19 PM, Dan Kaminsky wrote: > > The deal is that IP addresses are useless, host names are useful , but host > name spoofing is actually a real thing that real attackers do. > > So, either you don't log, you log hacker controlled data, or you UseDNS. > OpenSSH, optimizing for security, chooses the last of these options. > >> On Thursday, December 26, 2013, Kaz Kylheku wrote: >> >> >> >>> On 26.12.2013 09:27, Alex Bligh wrote: >>> >>>> On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: >>>> >>>> UseDNS Specifies whether sshd(8) should look up the remote host name >> and check that the resolved host name for the remote IP address maps back >> to the very same IP address. The default is ``yes''. >>> >>> I've often wondered why the default for this is 'yes'. >> >> I don't want to read reference manuals. I want software not to do stupid >> things by default. This misfeature and its configuration option >> shouldn't even exist. >> >> There isn't any action that the software can take based on this info. >> (We should never waste resources gathering info that cannot be used to >> take action.) >> >> You cannot reject hosts from making SSH connections just because they >> have inconsistent DNS. >> >> Such checks are sometimes useful in software that has no real security, >> like SMTP. Rejecting inconsistent DNS hosts is an amazingly reliable >> rule that will get rid of a large fraction of spam, with virtually no >> false positives. >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dan at doxpara.com Fri Dec 27 15:55:33 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 26 Dec 2013 20:55:33 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <6542005F-5864-4D5B-9849-AEFA40FFE11A@gmail.com> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> <6542005F-5864-4D5B-9849-AEFA40FFE11A@gmail.com> Message-ID: You can't not log. Logging IPs provides little useful information. Logging domains provides useful information, but is spoofable. Logging domains and verifying reverse DNS provides useful information, but alerts on broken DNS implementations. Those are the four choices. OpenSSH optimizes for security and not for tolerating bad system administration. That's sort of the deal. On Thursday, December 26, 2013, ag at gmail wrote: > If OpenSSH takes no action, this entry does seem pretty useless for the > functionality. I don't think it adds any real life security improvement, > but adds too much noise which will be ignored anyways. > > It may be useful to other log-analyzer software trying make sense, but > again the number of false positives render useless any meaningful > interpretation of these log entries as well. > > I can't think if a use case for this logging to be enabled by default, if > at all it needs to be there, but I may have missed the obvious (which > hasn't been yet discussed in this thread). > > Thanks. > > -coderaptor > > -- > sent via 100% recycled electrons from my mobile command center. > > > On Dec 26, 2013, at 2:19 PM, Dan Kaminsky > > wrote: > > > > The deal is that IP addresses are useless, host names are useful , but > host > > name spoofing is actually a real thing that real attackers do. > > > > So, either you don't log, you log hacker controlled data, or you UseDNS. > > OpenSSH, optimizing for security, chooses the last of these options. > > > >> On Thursday, December 26, 2013, Kaz Kylheku wrote: > >> > >> > >> > >>> On 26.12.2013 09:27, Alex Bligh wrote: > >>> > >>>> On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: > >>>> > >>>> UseDNS Specifies whether sshd(8) should look up the remote host name > >> and check that the resolved host name for the remote IP address maps > back > >> to the very same IP address. The default is ``yes''. > >>> > >>> I've often wondered why the default for this is 'yes'. > >> > >> I don't want to read reference manuals. I want software not to do stupid > >> things by default. This misfeature and its configuration option > >> shouldn't even exist. > >> > >> There isn't any action that the software can take based on this info. > >> (We should never waste resources gathering info that cannot be used to > >> take action.) > >> > >> You cannot reject hosts from making SSH connections just because they > >> have inconsistent DNS. > >> > >> Such checks are sometimes useful in software that has no real security, > >> like SMTP. Rejecting inconsistent DNS hosts is an amazingly reliable > >> rule that will get rid of a large fraction of spam, with virtually no > >> false positives. > >> > >> > >> _______________________________________________ > >> openssh-unix-dev mailing list > >> openssh-unix-dev at mindrot.org > >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From danm at prime.gushi.org Sat Dec 28 09:52:14 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Fri, 27 Dec 2013 14:52:14 -0800 (PST) Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: On Thu, 26 Dec 2013, Dan Kaminsky wrote: > The deal is that IP addresses are useless, host names are useful , but host > name spoofing is actually a real thing that real attackers do. > > So, either you don't log, you log hacker controlled data, or you UseDNS. > OpenSSH, optimizing for security, chooses the last of these options. I think the point here is that there's no option for openSSH to then *drop the connection* or refuse it. OpenSSH *checks*, but does not *enforce* anything. Sendmail will refuse to relay if my forward and reverse DNS don't match. If I have an Allow From *.example.edu in my apache config, apache requires them both to match or it won't let me in. OpenSSH will clutter my logs and do nothing else. Someone can hammer my root account for hours, trying various passwords, but SSH won't throw a warning until ssh reaches MaxAuthTries/2. But they better watch out if they have mismatched DNS! The only case where this feature might be useful is in cases where you have something like: Match host *.example.edu GSSAPIAuthentication Yes or even: Match host !*.example.edu GSSAPIAuthentication No PasswordAuthentication No ChallengeResponseAuthentication No (Effectively denying all but key-based login from outside networks you presumably control) At which point, as an admin at Example University, you probably want to see if you're getting a lot of spoofing. (Note that my openssh man pages don't say if using a Match Host explicitly checks forward and reverse, or only checks rdns). I also don't see a way to easily say "Deny all connections not from this host block". There's no PAM module that checks that DNS should match and refuses if it doesn't. (Maybe this should be a thing -- I think there's no provision to pass connecting IP address to PAM, but it could be added). Given, you can go ahead and install something like Fail2Ban and configure that to trawl your logs for this message, but this message comes up on either a successful login, or a failed one. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek --------------------------- From Coy.Hile at COYHILE.COM Sat Dec 28 13:09:24 2013 From: Coy.Hile at COYHILE.COM (Coy Hile) Date: Sat, 28 Dec 2013 02:09:24 +0000 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: Message-ID: On 12/26/13, 4:47 PM, "Kaz Kylheku" wrote: > > >On 26.12.2013 09:27, Alex Bligh wrote: > >> On 25 Dec 2013, at 08:04, Ben Lindstrom wrote: >> >>> UseDNS Specifies whether sshd(8) should look up the remote host name >>>and check that the resolved host name for the remote IP address maps >>>back to the very same IP address. The default is ``yes''. >> >> I've often wondered why the default for this is 'yes'. > >I don't want to read reference manuals. I want software not to do stupid >things by default. This misfeature and its configuration option >shouldn't even exist. > >There isn't any action that the software can take based on this info. >(We should never waste resources gathering info that cannot be used to >take action.) Imagine that you, as a sysadmin, perhaps control users? keys (and authorized_keys files per user, per host) centrally. In that use case, at least, you can enforce that certain keys only be allowed from certain hosts. I?d find UseDNS yes useful in that use case, as well as the GSSAPI use cases that others have mentioned in the thread. > From djm at mindrot.org Sat Dec 28 20:04:06 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 28 Dec 2013 20:04:06 +1100 (EST) Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: On Fri, 27 Dec 2013, Dan Mahoney, System Admin wrote: > I think the point here is that there's no option for openSSH to then > *drop the connection* or refuse it. OpenSSH *checks*, but does not > *enforce* anything. That's not entriely true. from=... restrictions in authorized_keys and "Match host" sections in sshd_config depend on the hostname. In the reverse-mapping check failed case, they don't get to see the original (probably untrustworthy) hostname and are just passed the IP address. Basically, the things that depend on the hostname will not be shown one that appears spoofed. -d From danm at prime.gushi.org Sat Dec 28 20:14:09 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Sat, 28 Dec 2013 01:14:09 -0800 (PST) Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: On Sat, 28 Dec 2013, Damien Miller wrote: > On Fri, 27 Dec 2013, Dan Mahoney, System Admin wrote: > >> I think the point here is that there's no option for openSSH to then >> *drop the connection* or refuse it. OpenSSH *checks*, but does not >> *enforce* anything. > > That's not entriely true. from=... restrictions in authorized_keys and > "Match host" sections in sshd_config depend on the hostname. In the > reverse-mapping check failed case, they don't get to see the original > (probably untrustworthy) hostname and are just passed the IP address. Right, and that was my point -- if you have a bunch of "match host" blocks, what do you put *outside* those blocks to just deny all connections? I don't see an option like "AllowUsers None" or "DenyUsers All" or "DenyUsers *", at least according to the manpage. In theory you could disable all authentication methods, which will cause login to fail, but there's no easy way to do an apache-style "deny from all", which in theory should happen even without doing a handshake in this situation. > Basically, the things that depend on the hostname will not be shown one > that appears spoofed. Okay, and will the things that depend on the hostname work at all if UseDNS is turned off? -Dan -- "A mother can be an inspiration to her little son, change his thoughts, his mind, his life, just with her gentle hum." -No Doubt, "Different People", from "Tragic Kingdom" --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From kaz at kylheku.com Sun Dec 29 02:24:57 2013 From: kaz at kylheku.com (Kaz Kylheku) Date: Sat, 28 Dec 2013 07:24:57 -0800 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> Message-ID: <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> On 27.12.2013 14:52, Dan Mahoney, System Admin wrote: > On Thu, 26 Dec 2013, Dan Kaminsky wrote: > >> The deal is that IP addresses are useless, host names are useful , but host name spoofing is actually a real thing that real attackers do. So, either you don't log, you log hacker controlled data, or you UseDNS. OpenSSH, optimizing for security, chooses the last of these options. > > I think the point here is that there's no option for openSSH to then *drop > the connection* or refuse it. OpenSSH *checks*, but does not > *enforce* anything. Sendmail will refuse to relay if my forward and > reverse DNS don't match. If I have an Allow From *.example.edu in > my apache config, apache requires them both to match or it won't > let me in. OpenSSH will clutter my logs and do nothing else Refusing such connections makes perfect sense in unauthenticated SMTP. Doing so will get rid of a large fraction of spam, with virtually no false positives. It makes no sense in SSH. You'd never want to refuse a connection which has the correct password or key just because it came from an IP address that doesn't have reversible DNS. This WHOLE THING IS MISFEATURE that shouldn't exist in the code, let alone be turned on by default. There is no reason for ssh to "use DNS" except in the client to resolve server addresses. Using DNS wastes TIME when you're logging in, creating a useless pause (which can be long if there is some DNS issue). LOOK AT THE GOOGLE SEARCH FOR "SLOW SSH LOGIN" [1].?Countless people have been bitten by long pauses when trying to log in to a server, and the culprit is the DNS lookup. I don't want to read manuals in order to discover software misfeatures and turn them off. Default configurations should be high-performing, secure, and free of misfeatures. Links: ------ [1] https://www.google.ca/search?q=slow+ssh+login From philipp.marek at linbit.com Sun Dec 29 05:45:29 2013 From: philipp.marek at linbit.com (Philipp Marek) Date: Sat, 28 Dec 2013 19:45:29 +0100 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> Message-ID: <106806722.yRQYi77sls@cacao> > > That's not entriely true. from=... restrictions in authorized_keys > > and "Match host" sections in sshd_config depend on the hostname. In > > the reverse-mapping check failed case, they don't get to see the > > original (probably untrustworthy) hostname and are just passed the > > IP address. > Right, and that was my point -- if you have a bunch of "match host" > blocks, what do you put *outside* those blocks to just deny all > connections? I don't see an option like "AllowUsers None" or > "DenyUsers All" or "DenyUsers *", at least according to the manpage. > > In theory you could disable all authentication methods, which will > cause login to fail, but there's no easy way to do an apache-style > "deny from all", which in theory should happen even without doing a > handshake in this situation. You can always just restrict to key-based authentication, and then say AuthorizedKeysFile /dev/null or use DenyUsers * From danm at prime.gushi.org Sun Dec 29 08:09:50 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Sat, 28 Dec 2013 13:09:50 -0800 (PST) Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <106806722.yRQYi77sls@cacao> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <106806722.yRQYi77sls@cacao> Message-ID: On Sat, 28 Dec 2013, Philipp Marek wrote: >>> That's not entriely true. from=... restrictions in authorized_keys >>> and "Match host" sections in sshd_config depend on the hostname. In >>> the reverse-mapping check failed case, they don't get to see the >>> original (probably untrustworthy) hostname and are just passed the >>> IP address. >> Right, and that was my point -- if you have a bunch of "match host" >> blocks, what do you put *outside* those blocks to just deny all >> connections? I don't see an option like "AllowUsers None" or >> "DenyUsers All" or "DenyUsers *", at least according to the manpage. >> >> In theory you could disable all authentication methods, which will >> cause login to fail, but there's no easy way to do an apache-style >> "deny from all", which in theory should happen even without doing a >> handshake in this situation. > You can always just restrict to key-based authentication, and then say > AuthorizedKeysFile /dev/null > > or use > DenyUsers * Hrmmm, yeah I suppose that is an allowed pattern, although I didn't quite grok that in the ssh_config manpage. It should probably be added to sshd_config's manpage for the allowusers/denyusers section. It's still a roundabout way to say "drop connection". There's also not a good way to throw a message out in-band. (In sendmail parlance, REJECT 553 "Go Away") At any rate, we're somewhat off-topic here, which I'll cover in another message in this thread. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From danm at prime.gushi.org Sun Dec 29 08:28:26 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Sat, 28 Dec 2013 13:28:26 -0800 (PST) Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> Message-ID: On Sat, 28 Dec 2013, Kaz Kylheku wrote: > > On 27.12.2013 14:52, Dan Mahoney, System Admin wrote: > > On Thu, 26 Dec 2013, Dan Kaminsky wrote: > The deal is that IP addresses are useless, host > names are useful , but host name spoofing is > actually a real thing that real attackers do. So, > either you don't log, you log hacker controlled > data, or you UseDNS. OpenSSH, optimizing for > security, chooses the last of these options. > > I think the point here is that there's no option for openSSH to then *drop > the connection* or refuse it. OpenSSH *checks*, but does not > *enforce* anything. Sendmail will refuse to relay if my forward and > reverse DNS don't match. If I have an Allow From *.example.edu in > my apache config, apache requires them both to match or it won't > let me in. OpenSSH will clutter my logs and do nothing else > > Refusing such connections makes perfect sense in unauthenticated SMTP. Doing > so will get rid of a large fraction of spam, with virtually no false > positives. > > It makes no sense in SSH. You'd never want to refuse a connection which has > the correct password or key just because it came from an IP address that > doesn't have reversible DNS. .. > There is no reason for ssh to "use DNS" except in the client to resolve > server addresses. Sure you would, and I cited an example where you might. However, here's my other question -- if you have such a restriction turned on (host-restricted config in sshd_config or authorized-keys), but UseDNS turned *off* will DNS still be used? Or will turning UseDNS off basically break these features? -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From mfriedl at gmail.com Mon Dec 30 03:28:27 2013 From: mfriedl at gmail.com (Markus Friedl) Date: Sun, 29 Dec 2013 17:28:27 +0100 Subject: sftp-server versus internal-sftp In-Reply-To: References: Message-ID: 1) internal-sftp is a hack that was added later for simplifying chroot setups 2) the login-shell is used for access-control in many cases, so skipping the shell might allow access for locked-out users. -m Am 24.12.2013 um 01:07 schrieb Parke : > Hi, > > I recently discovered that my ~/.bashrc file was preventing me from > using SFTP successfully. I then found documentation of sftp-server > and internal-sftp. However, I could not find answers to the following > questions in the documentation. > > 1) What are the advantages of sftp-server over internal-sftp? (I > believe Ubuntu and Debian both default to "Subsystem sftp > /usr/lib/openssh/sftp-server".) > > 2) What is the advantage of having the subsystem run sftp-server via > the user's shell, instead of just running sftp-server directly? > > Thanks! > > -Parke > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nicolai-openssh at chocolatine.org Mon Dec 30 03:48:35 2013 From: nicolai-openssh at chocolatine.org (Nicolai) Date: Sun, 29 Dec 2013 10:48:35 -0600 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> Message-ID: <20131229164835.GA15246@vectra.student.iastate.edu> On Sat, Dec 28, 2013 at 07:24:57AM -0800, Kaz Kylheku wrote: > There is no reason for ssh to "use DNS" except in the client to resolve > server addresses. SSH tunnels (with proxied DNS to avoid leaks) need UseDNS on the server. Nicolai From alex at alex.org.uk Mon Dec 30 22:43:09 2013 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 30 Dec 2013 11:43:09 +0000 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <20131229164835.GA15246@vectra.student.iastate.edu> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> <20131229164835.GA15246@vectra.student.iastate.edu> Message-ID: <85C03808-667E-4D22-9974-F987E2CF3712@alex.org.uk> On 29 Dec 2013, at 16:48, Nicolai wrote: >> >> There is no reason for ssh to "use DNS" except in the client to resolve >> server addresses. > > SSH tunnels (with proxied DNS to avoid leaks) need UseDNS on the server. Why? UseDNS looks up the peer's DNS records. If anything, I think you would want that switched off (precisely to avoid the server looking up the in-addr.arpa of the peer). -- Alex Bligh From nicolai-openssh at chocolatine.org Tue Dec 31 10:05:49 2013 From: nicolai-openssh at chocolatine.org (Nicolai) Date: Mon, 30 Dec 2013 17:05:49 -0600 Subject: Useless log message "POSSIBLE BREAK-IN ATTEMPT" In-Reply-To: <20131229164835.GA15246@vectra.student.iastate.edu> References: <6aeca5e46c19ce3a4354e53685471c7e@mail.kylheku.com> <49BA2C4A-8559-4CB9-BE18-720E945DD767@alex.org.uk> <72ab57be7eb62c03010ff6ead413449a@mail.kylheku.com> <20131229164835.GA15246@vectra.student.iastate.edu> Message-ID: <20131230230549.GA2373@vectra.student.iastate.edu> On Sun, Dec 29, 2013 at 10:48:35AM -0600, Nicolai wrote: > SSH tunnels (with proxied DNS to avoid leaks) need UseDNS on the server. This is not right. (Just did some testing on my end.) I improperly deduced this from what was probably a transient error having nothing to do with UseDNS. SSH tunnels do not require UseDNS for proxied DNS. My apologies for any confusion! Nicolai From cloos at jhcloos.com Tue Dec 31 12:49:15 2013 From: cloos at jhcloos.com (James Cloos) Date: Mon, 30 Dec 2013 20:49:15 -0500 Subject: Cipher preference Message-ID: When testing chacha20-poly1305, I noticed that aes-gcm is significantly faster than aes-ctr or aes-cbs with umac. Even on systems w/o aes-ni or other recent instruction set additions. And there seems to be consensus in the crypto community that AEAD ciphers are the way forward. As such, it promoting the AEAD ciphers to the head of the preference list looks like a good idea. That would mean either: #define KEX_DEFAULT_ENCRYPT \ AESGCM_CIPHER_MODES \ "chacha20-poly1305 at openssh.com," \ "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" or: #define KEX_DEFAULT_ENCRYPT \ "chacha20-poly1305 at openssh.com," \ AESGCM_CIPHER_MODES \ "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" The fact that AESGCM_CIPHER_MODES expands to "" when compiled against versions of openssl which lack EVPGCM may put a damper in that, but perhaps it still seems better to use whichever AEADs are available whenever they are available. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From djm at mindrot.org Tue Dec 31 13:43:15 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 31 Dec 2013 13:43:15 +1100 (EST) Subject: Cipher preference In-Reply-To: References: Message-ID: On Mon, 30 Dec 2013, James Cloos wrote: > When testing chacha20-poly1305, I noticed that aes-gcm is significantly > faster than aes-ctr or aes-cbs with umac. Even on systems w/o aes-ni > or other recent instruction set additions. > > And there seems to be consensus in the crypto community that AEAD > ciphers are the way forward. Lots of cryptographers also think that AES-GCM is fiendishly difficult to get right, especially wrt timing leaks. That, and it's relative newness in OpenSSH are the reasons it is not the default. -d From cloos at jhcloos.com Tue Dec 31 18:03:59 2013 From: cloos at jhcloos.com (James Cloos) Date: Tue, 31 Dec 2013 02:03:59 -0500 Subject: Cipher preference In-Reply-To: (Damien Miller's message of "Tue, 31 Dec 2013 13:43:15 +1100 (EST)") References: Message-ID: >>>>> "DM" == Damien Miller writes: DM> Lots of cryptographers also think that AES-GCM is fiendishly difficult DM> to get right, especially wrt timing leaks. That, and it's relative DM> newness in OpenSSH are the reasons it is not the default. Indeed, I should have added a paragraph about that. My understanding is that the consensus is that openssl has fixed the early bugs in its implementation and gcm therefore is safe enough to promote. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6