From dajoker at gmail.com Wed Jan 2 02:39:56 2013 From: dajoker at gmail.com (Me) Date: Tue, 1 Jan 2013 08:39:56 -0700 Subject: ssh-copy-id enhancement 2013-01-01 Message-ID: I and others have enjoyed using the ssh-copy-id script for most systems, but when port numbers on target systems are changed it goes from being trivial to use to requiring a decent knowledge of how to set target ports on the client side in other ways (for example, ~/.ssh/config or something like that). Since these cases are the exception it'd be nice if ssh-copy-id could handle alternate ports from the calling command like 'ssh' and 'scp' (and others) do. To this end I am attaching a unified-diff file with changes that implement this. I've done basic testing on systems both with and without alternate ports and believe it works fairly well. For the forum thread that started all of this (finally convinced me to fix it for myself too) see the following from openSUSE, if interested: http://forums.opensuse.org/showthread.php?t=481944 I built this against the ssh-copy-id file in ./openssh/contrib from cvs, though the script exactly matches (compared via checksum) the one that openSUSE 12.2 ships as well. I also attached the modified script just in case I somehow unified-diff'd incorrectly (I'm not a programmer by trade; it's possible/likely I fouled something up). Happy New Year, Aaron Burgemeister From s.priebe at profihost.ag Thu Jan 3 09:29:14 2013 From: s.priebe at profihost.ag (Stefan Priebe) Date: Wed, 02 Jan 2013 23:29:14 +0100 Subject: ssh / scp slow on 10GBE Message-ID: <50E4B4BA.7050906@profihost.ag> Hello list, right now SSH Tunnel / scp is reaches just around 76Mb/s on my E5 Xeon using AES-NI but openssl reaches around 600-700Mb/s using 128aes-cbc cipher. As far as i understand http://www.psc.edu/index.php/hpn-ssh this is due to very small buffers in ssh / scp. Is there any work on this? Like autotuning the buffer size? Are there plans to integrate the hpn patches? Greets, Stefan From imorgan at nas.nasa.gov Fri Jan 4 06:19:07 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 3 Jan 2013 11:19:07 -0800 Subject: ssh / scp slow on 10GBE In-Reply-To: <50E4B4BA.7050906@profihost.ag> References: <50E4B4BA.7050906@profihost.ag> Message-ID: <20130103191907.GB3451@linux124.nas.nasa.gov> On Wed, Jan 02, 2013 at 16:29:14 -0600, Stefan Priebe wrote: > Hello list, > > right now SSH Tunnel / scp is reaches just around 76Mb/s on my E5 Xeon > using AES-NI but openssl reaches around 600-700Mb/s using 128aes-cbc cipher. > > As far as i understand http://www.psc.edu/index.php/hpn-ssh this is due > to very small buffers in ssh / scp. > > Is there any work on this? Like autotuning the buffer size? Are there > plans to integrate the hpn patches? > > Greets, > Stefan I think you have a typo above. You presumably mean 600-700 MB/s in the case of OpenSSL using AES-NI, but do you mean MB/s or Mb/s in the scp case? How are you measuring the ssh/scp performance? Is this over a LAN or WAN connection? The issue which the HPN patch addresses is the sizing of the channel buffer. This can be helpful in the case of high-latency (strictly, high BDP) connections. If you are truly getting 76 Mb/s (i.e. 9-10 MB/s) and the transfer is over a high-latency (WAN) connection, then the HPN patch may be of benefit. On the other hand, if you are getting 76 MB/s, then you may have some other bottlenecck to address. You might try doing a dd through ssh to factor out scp and disk I/O. For example, % dd if=/dev/zero bs=1048576 count=4096 | ssh somehost dd of=/dev/null As to adding something like the HPN functionality to stock OpenSSH, I'll leave that to the OpenSSH developers to comment on. I believe that OpenBSD added TCP autotuning (or something roughly analogous) to their kernel a few releases ago. If that is the case, it would seem to increase the likelihood of something similar to the HPN dynamic windowing patch being added to OpenSSH. -- Iain Morgan From s.priebe at profihost.ag Fri Jan 4 22:44:46 2013 From: s.priebe at profihost.ag (Stefan Priebe) Date: Fri, 04 Jan 2013 12:44:46 +0100 Subject: ssh / scp slow on 10GBE In-Reply-To: <20130103191907.GB3451@linux124.nas.nasa.gov> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> Message-ID: <50E6C0AE.9050104@profihost.ag> Hi, Am 03.01.2013 20:19, schrieb Iain Morgan: > I think you have a typo above. You presumably mean 600-700 MB/s in the > case of OpenSSL using AES-NI, but do you mean MB/s or Mb/s in the scp > case? uups i mean MB in both cases. > How are you measuring the ssh/scp performance? Is this over a LAN or WAN > connection? LAN > On the other hand, if you are getting 76 MB/s, then you may have some > other bottlenecck to address. You might try doing a dd through ssh to > factor out scp and disk I/O. For example, > > % dd if=/dev/zero bs=1048576 count=4096 | ssh somehost dd of=/dev/null #~ dd if=/dev/zero bs=1048576 count=4096 | ssh -c aes128-cbc 10.255.0.24 dd of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4,3 GB) copied, 19,3355 s, 222 MB/s 8388608+0 records in 8388608+0 records out 4294967296 bytes (4,3 GB) copied, 18,6107 s, 231 MB/s But: # iperf -c 10.255.0.24 -t 30 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.255.0.24, TCP port 5001 TCP window size: 990 KByte (default) ------------------------------------------------------------ [ 4] local 10.255.0.22 port 44006 connected with 10.255.0.24 port 5001 [ 5] local 10.255.0.22 port 5001 connected with 10.255.0.24 port 37393 [ ID] Interval Transfer Bandwidth [ 4] 0.0-30.0 sec 34.6 GBytes 9.90 Gbits/sec [ 5] 0.0-30.0 sec 33.9 GBytes 9.70 Gbits/sec and openssl aes-128-cbc speed: The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 648664.33k 688924.90k 695855.45k 700784.64k 704027.06k Greets, Stefan From tomas.kuthan at oracle.com Sat Jan 5 00:04:40 2013 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Fri, 04 Jan 2013 14:04:40 +0100 Subject: ssh / scp slow on 10GBE In-Reply-To: <50E6C0AE.9050104@profihost.ag> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> Message-ID: <50E6D368.9060700@oracle.com> On 01/04/13 12:44, Stefan Priebe wrote: > Hi, > > Am 03.01.2013 20:19, schrieb Iain Morgan: >> I think you have a typo above. You presumably mean 600-700 MB/s in the >> case of OpenSSL using AES-NI, but do you mean MB/s or Mb/s in the scp >> case? > uups i mean MB in both cases. > >> How are you measuring the ssh/scp performance? Is this over a LAN or WAN >> connection? > LAN > >> On the other hand, if you are getting 76 MB/s, then you may have some >> other bottlenecck to address. You might try doing a dd through ssh to >> factor out scp and disk I/O. For example, >> >> % dd if=/dev/zero bs=1048576 count=4096 | ssh somehost dd of=/dev/null > #~ dd if=/dev/zero bs=1048576 count=4096 | ssh -c aes128-cbc 10.255.0.24 > dd of=/dev/null > 4096+0 records in > 4096+0 records out > 4294967296 bytes (4,3 GB) copied, 19,3355 s, 222 MB/s > 8388608+0 records in > 8388608+0 records out > 4294967296 bytes (4,3 GB) copied, 18,6107 s, 231 MB/s > > But: > # iperf -c 10.255.0.24 -t 30 -d > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > ------------------------------------------------------------ > Client connecting to 10.255.0.24, TCP port 5001 > TCP window size: 990 KByte (default) > ------------------------------------------------------------ > [ 4] local 10.255.0.22 port 44006 connected with 10.255.0.24 port 5001 > [ 5] local 10.255.0.22 port 5001 connected with 10.255.0.24 port 37393 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-30.0 sec 34.6 GBytes 9.90 Gbits/sec > [ 5] 0.0-30.0 sec 33.9 GBytes 9.70 Gbits/sec > > and > openssl aes-128-cbc speed: > > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > aes-128-cbc 648664.33k 688924.90k 695855.45k 700784.64k > 704027.06k > > Greets, > Stefan > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Hi Stefan, in order for ssh receive window to not impose an additional bottleneck, it should be set to be roughly equal to bandwidth-delay-product. Taking into account your measured bandwidth of about 1.2 GBps, and assuming round-trip-time on LAN lesser or equal to 1 ms, OpenSSH's hard-coded window size 2 MB should be just about enough: 1.2 GBps * RTT <= 1200 MBps * 0.001 s < 2 MB Just to make sure, could you please measure round-trip-time on the connection? Simply running ping will do... If the result is not 2 ms or higher, ssh window side is most probably not the culprit. Part of the gap between encryption speed and the dd measurement can be accounted to checksumming, some to initial key-exchange and rekeying. The gap still feels quite wide though. I don't know, how your initial measurements (76 MBps) were done. But if it involved copying multiple smaller files, this could very well be scp protocol overhead. In that case tar could help. Cheers, Tomas From imorgan at nas.nasa.gov Sat Jan 5 06:08:27 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 4 Jan 2013 11:08:27 -0800 Subject: ssh / scp slow on 10GBE In-Reply-To: <50E6C0AE.9050104@profihost.ag> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> Message-ID: <20130104190827.GA12927@linux124.nas.nasa.gov> On Fri, Jan 04, 2013 at 05:44:46 -0600, Stefan Priebe wrote: > Hi, > > Am 03.01.2013 20:19, schrieb Iain Morgan: > > I think you have a typo above. You presumably mean 600-700 MB/s in the > > case of OpenSSL using AES-NI, but do you mean MB/s or Mb/s in the scp > > case? > uups i mean MB in both cases. > > > How are you measuring the ssh/scp performance? Is this over a LAN or WAN > > connection? > LAN > > > On the other hand, if you are getting 76 MB/s, then you may have some > > other bottlenecck to address. You might try doing a dd through ssh to > > factor out scp and disk I/O. For example, > > > > % dd if=/dev/zero bs=1048576 count=4096 | ssh somehost dd of=/dev/null > #~ dd if=/dev/zero bs=1048576 count=4096 | ssh -c aes128-cbc 10.255.0.24 > dd of=/dev/null > 4096+0 records in > 4096+0 records out > 4294967296 bytes (4,3 GB) copied, 19,3355 s, 222 MB/s > 8388608+0 records in > 8388608+0 records out > 4294967296 bytes (4,3 GB) copied, 18,6107 s, 231 MB/s > > But: > # iperf -c 10.255.0.24 -t 30 -d > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > ------------------------------------------------------------ > Client connecting to 10.255.0.24, TCP port 5001 > TCP window size: 990 KByte (default) > ------------------------------------------------------------ > [ 4] local 10.255.0.22 port 44006 connected with 10.255.0.24 port 5001 > [ 5] local 10.255.0.22 port 5001 connected with 10.255.0.24 port 37393 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-30.0 sec 34.6 GBytes 9.90 Gbits/sec > [ 5] 0.0-30.0 sec 33.9 GBytes 9.70 Gbits/sec > > and > openssl aes-128-cbc speed: > > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > aes-128-cbc 648664.33k 688924.90k 695855.45k 700784.64k 704027.06k > > Greets, > Stefan > As Tomas noted, the choice of MAC also impacts performance. The default is hmac-md5, but umac-64 at openssh.com can provide significantly better performance. I'm assuming that the number you quoted in your original email was from an scp transfer. Be aware that it uses fairly coarse time granularity in its calculations, so transfers of small files can report deceptive values. You may also want to check the disk I/O performance on both ends of the transfer. -- Iain Morgan From openssh at roumenpetrov.info Sun Jan 6 00:10:39 2013 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 05 Jan 2013 15:10:39 +0200 Subject: X.509 certificate support version 7.4 is available for download Message-ID: <50E8264F.2030006@roumenpetrov.info> Dear All, Version 7.4 of X.509 certificates support for OpenSSH was published yesterday. New feature: - RSASHA1 algorithm for DNS CERT RR as described in RFC 4034 Deprecated option X509rsaSigType is finally removed. More detailed description is available on http://roumenpetrov.info/openssh/ Yours sincerely, Roumen Petrov From s.priebe at profihost.ag Mon Jan 7 05:54:46 2013 From: s.priebe at profihost.ag (Stefan Priebe) Date: Sun, 06 Jan 2013 19:54:46 +0100 Subject: ssh / scp slow on 10GBE In-Reply-To: <20130104190827.GA12927@linux124.nas.nasa.gov> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> Message-ID: <50E9C876.50800@profihost.ag> Hi Iain, Am 04.01.2013 20:08, schrieb Iain Morgan: >> openssl aes-128-cbc speed: >> >> The 'numbers' are in 1000s of bytes per second processed. >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 >> bytes >> aes-128-cbc 648664.33k 688924.90k 695855.45k 700784.64k 704027.06k > > As Tomas noted, the choice of MAC also impacts performance. The default > is hmac-md5, but umac-64 at openssh.com can provide significantly better > performance. Oh i didn't saw tomas mail - maybe he just replied to the list. I'm not subscribed. But i found his mail and will reply in a seperate email. I tried now umac-64 at openssh.com this gives me 400MB/s - is this the maximum i can expect through 10GBE? Link shows avg rate of 6,5Gbit/s. > I'm assuming that the number you quoted in your original email was from > an scp transfer. Be aware that it uses fairly coarse time granularity in > its calculations, so transfers of small files can report deceptive > values. Yes it was from scp but just transfering one 20GB file. But i missed the disk speed problematic. In my original task i would just like to transfer as much data as possible (in memory - no disks involved). Greets, Stefan From s.priebe at profihost.ag Mon Jan 7 06:00:13 2013 From: s.priebe at profihost.ag (Stefan Priebe) Date: Sun, 06 Jan 2013 20:00:13 +0100 Subject: ssh / scp slow on 10GBE In-Reply-To: <20130104190827.GA12927@linux124.nas.nasa.gov> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> Message-ID: <50E9C9BD.6050000@profihost.ag> Hi Tomas, >Just to make sure, could you please measure round-trip-time on the >connection? Simply running ping will do... While running: #~: dd if=/dev/zero bs=1048576 count=8192 | ssh -c aes128-cbc -m umac-64 at openssh.com 10.255.0.24 dd of=/dev/null 8192+0 records in 8192+0 records out 8589934592 bytes (8,6 GB) copied, 21,8169 s, 394 MB/s 16777216+0 records in 16777216+0 records out 8589934592 bytes (8,6 GB) copied, 21,1476 s, 406 MB/s These are the ping stats: 22 packets transmitted, 22 received, 0% packet loss, time 20996ms rtt min/avg/max/mdev = 0.060/0.103/0.176/0.026 ms >If the result is not 2 ms or higher, ssh window side is most probably >not the culprit. OK thanks for this info. >Part of the gap between encryption speed and the dd measurement can be >accounted to checksumming, some to initial key-exchange and rekeying. >The gap still feels quite wide though. Now it's 400MB/s using ssh and 1230MB/s when using a direct TCP connection. > don't know, how your initial measurements (76 MBps) were done. But if >it involved copying multiple smaller files, this could very well be scp >protocol overhead. In that case tar could help. Yes sorry scp and a disk was involved. I'm now talking about 400MB/s vs. 1230MB/s. Greets, Stefan From keisial at gmail.com Mon Jan 7 08:52:30 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 06 Jan 2013 22:52:30 +0100 Subject: ssh-copy-id enhancement 2013-01-01 In-Reply-To: References: Message-ID: <50E9F21E.6020009@gmail.com> On 01/01/13 16:39, Aaron Burgemeister wrote: > I and others have enjoyed using the ssh-copy-id script for most systems, > but when port numbers on target systems are changed it goes from being > trivial to use to requiring a decent knowledge of how to set target ports > on the client side in other ways (for example, ~/.ssh/config or something > like that). Since these cases are the exception it'd be nice if > ssh-copy-id could handle alternate ports from the calling command like > 'ssh' and 'scp' (and others) do. To this end I am attaching a unified-diff > file with changes that implement this. I've done basic testing on systems > both with and without alternate ports and believe it works fairly well. > > For the forum thread that started all of this (finally convinced me to fix > it for myself too) see the following from openSUSE, if interested: > http://forums.opensuse.org/showthread.php?t=481944 > > I built this against the ssh-copy-id file in ./openssh/contrib from cvs, > though the script exactly matches (compared via checksum) the one that > openSUSE 12.2 ships as well. I also attached the modified script just in > case I somehow unified-diff'd incorrectly (I'm not a programmer by trade; > it's possible/likely I fouled something up). > > Happy New Year, > Aaron Burgemeister Happy New Year, Aaron. The mailing list stripped your attachment (not sent with a text/plain mimetype ?), but it's probably the one at http://forums.opensuse.org/english/get-technical-help-here/network-internet/481944-cant-connect-thru-ssh-port-54545-any-port-other-than-default.html#post2514812 I recommend you to send it as a unified diff. It looks good, but I would have added the new option it *before* the host name. Interestingly, you can make ssh-copy-id work with a non-standard port by abusing the hostname field: > $ ssh-copy-id "-p 54545 apogee at apogee.suse.lst" From tomas.kuthan at oracle.com Mon Jan 7 21:41:47 2013 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Mon, 07 Jan 2013 11:41:47 +0100 Subject: ssh / scp slow on 10GBE In-Reply-To: <50E9C9BD.6050000@profihost.ag> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> <50E9C9BD.6050000@profihost.ag> Message-ID: <50EAA66B.2060406@oracle.com> Hi Stefan, sorry for the list-only reply. Some answers in-line... On 01/06/13 20:00, Stefan Priebe wrote: > Hi Tomas, > >>Just to make sure, could you please measure round-trip-time on the >>connection? Simply running ping will do... > > While running: > #~: dd if=/dev/zero bs=1048576 count=8192 | ssh -c aes128-cbc -m > umac-64 at openssh.com 10.255.0.24 dd of=/dev/null > 8192+0 records in > 8192+0 records out > 8589934592 bytes (8,6 GB) copied, 21,8169 s, 394 MB/s > 16777216+0 records in > 16777216+0 records out > 8589934592 bytes (8,6 GB) copied, 21,1476 s, 406 MB/s > > These are the ping stats: > 22 packets transmitted, 22 received, 0% packet loss, time 20996ms > rtt min/avg/max/mdev = 0.060/0.103/0.176/0.026 ms Thanks for the confirmation. In that case window size is sufficient. So most probably the transfer speed in your case is CPU-bound. You may want to run 'openssl speed' also on the receiving side, just to make sure. Alternatively you could compare this result with the same test run over localhost. >>If the result is not 2 ms or higher, ssh window side is most probably >>not the culprit. > OK thanks for this info. > >>Part of the gap between encryption speed and the dd measurement can be >>accounted to checksumming, some to initial key-exchange and rekeying. >>The gap still feels quite wide though. > Now it's 400MB/s using ssh and 1230MB/s when using a direct TCP connection. Well, you certainly won't get anything faster than your 700 MB of openssl aes speed results. You cannot transmit data faster, than you encrypt them. And even this upper bound is not reachable, because of checksumming overhead. In fact, taken into account the relative improvement when switching to umac-64 at openssh.com (230 -> 400 MBps), it is quite plausible, that all what remains, is due to checksum computation. Looks like 400 MBps is all you can get in current situation. Unless off course, you are willing to condescend to using weaker crypto (arcfour), which cannot be encouraged (I suppose, integrity and confidentiality are required). There is a potential in enhancing OpenSSH to do some tasks in parallel. MACs and encryption could be done at the same time. Or, for some modes of encryption, counters can be pre-computed in advance. But in the past OpenSSH developers expressed strongly against threads... Best regards, Tomas >> don't know, how your initial measurements (76 MBps) were done. But if >>it involved copying multiple smaller files, this could very well be scp >>protocol overhead. In that case tar could help. > Yes sorry scp and a disk was involved. I'm now talking about 400MB/s vs. > 1230MB/s. > > Greets, > Stefan From djm at mindrot.org Mon Jan 7 21:57:01 2013 From: djm at mindrot.org (Damien Miller) Date: Mon, 7 Jan 2013 21:57:01 +1100 (EST) Subject: ssh / scp slow on 10GBE In-Reply-To: <50EAA66B.2060406@oracle.com> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> <50E9C9BD.6050000@profihost.ag> <50EAA66B.2060406@oracle.com> Message-ID: On Mon, 7 Jan 2013, Tomas Kuthan wrote: > >>Part of the gap between encryption speed and the dd measurement can be > >>accounted to checksumming, some to initial key-exchange and rekeying. > >>The gap still feels quite wide though. > > Now it's 400MB/s using ssh and 1230MB/s when using a direct TCP connection. > > Well, you certainly won't get anything faster than your 700 MB of > openssl aes speed results. You cannot transmit data faster, than you > encrypt them. And even this upper bound is not reachable, because of > checksumming overhead. Right: if you are using AES and umac-64 as your MAC then you are actually invoking AES twice as umac-64 uses AES internally. > There is a potential in enhancing OpenSSH to do some tasks in parallel. > MACs and encryption could be done at the same time. Or, for some modes > of encryption, counters can be pre-computed in advance. But in the past > OpenSSH developers expressed strongly against threads... Yeah, we do don't want to go there (threads in OpenSSH). You might be able to make an OpenSSL engine implementation that manages it all on the OpenSSL side. Alternately, we are considering adding support for AES-GCM which is very fast on recent Intel CPUs and probably slightly faster than AES+umac-64 everywhere. -d From andrew at acooke.org Tue Jan 8 00:27:13 2013 From: andrew at acooke.org (andrew cooke) Date: Mon, 7 Jan 2013 10:27:13 -0300 Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: <20130107132713.GN5006@acooke.org> Just FYI, this patch (host keys via PKCS11) doesn't appear to call C_CloseSession. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From imorgan at nas.nasa.gov Tue Jan 8 05:59:12 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 7 Jan 2013 10:59:12 -0800 Subject: ssh / scp slow on 10GBE In-Reply-To: <50E9C876.50800@profihost.ag> References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> <50E9C876.50800@profihost.ag> Message-ID: <20130107185912.GB12927@linux124.nas.nasa.gov> On Sun, Jan 06, 2013 at 12:54:46 -0600, Stefan Priebe wrote: > Hi Iain, > > Am 04.01.2013 20:08, schrieb Iain Morgan: > >> openssl aes-128-cbc speed: > >> > >> The 'numbers' are in 1000s of bytes per second processed. > >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > >> bytes > >> aes-128-cbc 648664.33k 688924.90k 695855.45k 700784.64k 704027.06k > > > > As Tomas noted, the choice of MAC also impacts performance. The default > > is hmac-md5, but umac-64 at openssh.com can provide significantly better > > performance. > Oh i didn't saw tomas mail - maybe he just replied to the list. I'm not > subscribed. But i found his mail and will reply in a seperate email. > > I tried now umac-64 at openssh.com this gives me 400MB/s - is this the > maximum i can expect through 10GBE? Link shows avg rate of 6,5Gbit/s. > > > I'm assuming that the number you quoted in your original email was from > > an scp transfer. Be aware that it uses fairly coarse time granularity in > > its calculations, so transfers of small files can report deceptive > > values. > Yes it was from scp but just transfering one 20GB file. But i missed the > disk speed problematic. In my original task i would just like to > transfer as much data as possible (in memory - no disks involved). > > Greets, > Stefan You may be able to further improve the performance by using aes128-ctr instead of aes128-cbc. However, you will need to build OpenSSH from a recent snapshot[1] to take advantage of this. You can find more details in the list archive for December. -- Iain Morgan [1] http://www.mindrot.org/openssh_snap/ From naddy at mips.inka.de Tue Jan 8 08:05:18 2013 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon, 7 Jan 2013 21:05:18 +0000 (UTC) Subject: ssh / scp slow on 10GBE References: <50E4B4BA.7050906@profihost.ag> <50E9C9BD.6050000@profihost.ag> <50EAA66B.2060406@oracle.com> Message-ID: Damien Miller wrote: > > Well, you certainly won't get anything faster than your 700 MB of > > openssl aes speed results. You cannot transmit data faster, than you > > encrypt them. And even this upper bound is not reachable, because of > > checksumming overhead. > > Right: if you are using AES and umac-64 as your MAC then you are actually > invoking AES twice as umac-64 uses AES internally. That's misleading. UMAC uses AES only to encrypt its final hash (somewhat like GMAC). It does not run all the data through AES. > Alternately, we are considering adding support for AES-GCM which is very > fast on recent Intel CPUs and probably slightly faster than AES+umac-64 > everywhere. I doubt it. Check "openssl speed md5 sha1 sha256 ghash". Figures vary across architectures and machines, but GHASH performance for large blocks seems broadly similar to SHA-1 and slower than MD5. -- Christian "naddy" Weisgerber naddy at mips.inka.de From rick.patterson at hotmail.com Wed Jan 9 02:25:43 2013 From: rick.patterson at hotmail.com (Rick Patterson) Date: Tue, 8 Jan 2013 10:25:43 -0500 Subject: sftp "cd" command to drive letter under cygwin Message-ID: Hello. When using sftp under cygwin, a "cd d:" attempt to change to the d: drive, results in the following: sftp> cd d:/ Couldn't canonicalise: No such file or directory. It can only be done by using a cygdrive-type path: sftp> cd /cygdrive/d sftp> pwd Remote working directory: /cygdrive/d sftp> yet a local cd (lcd) works fine. "lcd d:" works, and then lpwd prints a cygdrive path (which is fine). sftp> lcd d:/ sftp> lpwd Local working directory: /cygdrive/d I submitted this problem to the cygwin forum, but perhaps that was not the correct place: http://cygwin.com/ml/cygwin/2012-12/msg00160.html Since cygwin is supposed to support DOS paths as well as UNIX paths, and the lcd is working, I thought I'd take a look at it. I found the make_absolute function in sftp.c was assuming an absolute path starts with '/', but this is not true on Windows. I think the attached sftp.c.diff file is the fix, for your review, although there is a behavior change I'd like to discuss below. Previously, under Cygwin, in sftp, "cd d:" would not work, unless there was a sub-directory in the current working directory that was named "d:", which is allowed on the UNIX file system, as ":" is an allowed file name character. With the proposed change, assuming you want to "cd to d:" (where d: is a drive specification, and therefore an absolute path), the cd now works to the absolute path "d:" thereby supporting DOS paths. However, it also changes the previous behavior, as "cd d:" will now not go to the sub-directory "d:" if it exists, unless it is qualified as "./d:" A "d:" needs to be treated firstly as an absolute path before a sub-directory. This allows the previously ambiguous behavior to still work if required, but only by qualifying it as a sub-directory. I agree a batter fix might be that "if d:" does not exist as a drive letter, but there is a "d:" sub-directory, then cd to the d: sub-directory. This fix as proposed does not do this. I've tested the cd command under the Cygwin command line shell - it does appear to be able to conditionally cd to d: as a DOS drive if it exists, ignoring a d: sub-directory that exists. However, if x: does not exist as a drive letter, but does exist as a sub-directory then it does cd to x:. I believe an extra call from the sftp client to the sftp server would be required to do the conditional cd in sftp to be consistent with the Cygwin command line, but this would be beyond my abilities. Rick From peter at stuge.se Wed Jan 9 04:35:50 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 Jan 2013 18:35:50 +0100 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: References: Message-ID: <20130108173550.14072.qmail@stuge.se> Rick Patterson wrote: > When using sftp under cygwin, a "cd d:" attempt to change to the d: > drive, results in the following: > sftp> cd d:/ > Couldn't canonicalise: No such file or directory. Your quote is "cd d:" but your command is "cd d:/" and those are different, so the above part is not very clear. Please clarify. > Since cygwin is supposed to support DOS paths as well as UNIX > paths, and the lcd is working, I thought I'd take a look at it. I > found the make_absolute function in sftp.c was assuming an absolute > path starts with '/', but this is not true on Windows. I think > the attached sftp.c.diff file is the fix, for your review, although > there is a behavior change I'd like to discuss below. Why would a behavior change be acceptable? Any change that you make must affect only Windows, and nothing else. > Previously, under Cygwin, in sftp, "cd d:" would not work, unless > there was a sub-directory in the current working directory that was > named "d:", which is allowed on the UNIX file system, as ":" is an > allowed file name character. With the proposed change, assuming > you want to "cd to d:" (where d: is a drive specification, and > therefore an absolute path), Stop right here. "d:" is *NOT* an absolute path on Windows systems. I'm sure you know that DOS and Windows both keep track of the current working directory per drive. "d:" changes working drive, but does NOT change current working directory either on the current driver or on d:. "d:\" and "d:/" are absolute paths. > the cd now works to the absolute path "d:" thereby supporting DOS > paths. However, it also changes the previous behavior, as "cd d:" > will now not go to the sub-directory "d:" if it exists, unless it > is qualified as "./d:" I can not understand why you would modify behavior for every other platform as well. Isn't it absolutely obvious that whatever change you do in order to improve this on Windows must have *NO* effect on the vast majority of other operating systems that OpenSSH supports? > A "d:" needs to be treated firstly as an absolute path before a > sub-directory. On Cygwin, "d:" is a path relative to the current working directory on drive d. Everywhere else, it is a path relative to the current working directory. > I agree a batter fix might be that "if d:" does not exist as a > drive letter, but there is a "d:" sub-directory, then cd to the > d: sub-directory. Absolutely not, in my opinion. You are proposing to add a heuristic into the user interface. Sorry, but that is just horrible. > I've tested the cd command under the Cygwin command line shell - it > does appear to be able to conditionally cd to d: as a DOS drive if > it exists, ignoring a d: sub-directory that exists. However, if > x: does not exist as a drive letter, but does exist as a > sub-directory then it does cd to x:. I believe an extra call from > the sftp client to the sftp server would be required to do the > conditional cd in sftp to be consistent with the Cygwin command > line, but this would be beyond my abilities. I'd suggest to look at the Cygwin source code to find out how exactly chdir() is implemented, and to make sftp-server implement the same algorithm. The client shouldn't have to be involved in this at all. (Unless Cygwin patches all shells to make multiple chdir() calls, but I find that somewhat unlikely.) //Peter From nickolai at csail.mit.edu Wed Jan 9 04:36:22 2013 From: nickolai at csail.mit.edu (Nickolai Zeldovich) Date: Tue, 8 Jan 2013 12:36:22 -0500 (EST) Subject: [PATCH] avoid undefined behavior in fmt_scaled() Message-ID: fmt_scaled() computes the absolute value of its argument, and returns an error if the result is still negative (i.e., when the value is LLONG_MIN). However, taking the negative of LLONG_MIN is undefined behavior in C, and some compilers (e.g., gcc-4.7.2) will optimize away the 'abval < 0' check as being always false (since it can only be true with undefined behavior). The patch below performs an equivalent check without invoking undefined behavior. Nickolai. --- openssh-6.1p1/openbsd-compat/fmt_scaled.c 2008-05-19 18:57:08.000000000 -0400 +++ openssh-6.1p1/openbsd-compat/fmt_scaled.c 2013-01-08 12:18:29.883527421 -0500 @@ -196,12 +196,16 @@ unsigned int i; unit_type unit = NONE; + /* Not every negative long long has a positive representation. */ + if (number == LLONG_MIN) { + errno = ERANGE; + return -1; + } + abval = (number < 0LL) ? -number : number; /* no long long_abs yet */ - /* Not every negative long long has a positive representation. - * Also check for numbers that are just too darned big to format - */ - if (abval < 0 || abval / 1024 >= scale_factors[SCALE_LENGTH-1]) { + /* Check for numbers that are just too darned big to format. */ + if (abval / 1024 >= scale_factors[SCALE_LENGTH-1]) { errno = ERANGE; return -1; } From vinschen at redhat.com Wed Jan 9 06:13:09 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 8 Jan 2013 20:13:09 +0100 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: <20130108173550.14072.qmail@stuge.se> References: <20130108173550.14072.qmail@stuge.se> Message-ID: <20130108191309.GA12920@calimero.vinschen.de> On Jan 8 18:35, Peter Stuge wrote: > Rick Patterson wrote: > > When using sftp under cygwin, a "cd d:" attempt to change to the d: > > drive, results in the following: > > sftp> cd d:/ > > Couldn't canonicalise: No such file or directory. > > Your quote is "cd d:" but your command is "cd d:/" and those are > different, so the above part is not very clear. Please clarify. > > > > Since cygwin is supposed to support DOS paths as well as UNIX > > paths, and the lcd is working, I thought I'd take a look at it. I > > found the make_absolute function in sftp.c was assuming an absolute > > path starts with '/', but this is not true on Windows. I think > > the attached sftp.c.diff file is the fix, for your review, although > > there is a behavior change I'd like to discuss below. > > Why would a behavior change be acceptable? Any change that you make > must affect only Windows, and nothing else. > > > > Previously, under Cygwin, in sftp, "cd d:" would not work, unless > > there was a sub-directory in the current working directory that was > > named "d:", which is allowed on the UNIX file system, as ":" is an > > allowed file name character. With the proposed change, assuming > > you want to "cd to d:" (where d: is a drive specification, and > > therefore an absolute path), > > Stop right here. "d:" is *NOT* an absolute path on Windows systems. > > I'm sure you know that DOS and Windows both keep track of the current > working directory per drive. "d:" changes working drive, but does NOT > change current working directory either on the current driver or on d:. > "d:\" and "d:/" are absolute paths. This isn't correct. Cygwin doesn't follow the lead of the CMD shell here. As a POSIX layer it only keeps track of a single CWD, in POSIX and native NT notation. Therefore, on Cygwin, d: is an absolute path, too. However, DOS paths are only barely supported. The right thing to do is NOT to use DOS paths, but the equivalent POSIX path. This is also documented in the User's Guide: http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 > I'd suggest to look at the Cygwin source code to find out how exactly > chdir() is implemented, and to make sftp-server implement the same > algorithm. The client shouldn't have to be involved in this at all. > (Unless Cygwin patches all shells to make multiple chdir() calls, but > I find that somewhat unlikely.) There's no reason to change anything. Don't use DOS paths in Cygwin applications. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rick.patterson at hotmail.com Wed Jan 9 07:34:34 2013 From: rick.patterson at hotmail.com (Rick Patterson) Date: Tue, 8 Jan 2013 15:34:34 -0500 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: <20130108173550.14072.qmail@stuge.se> References: , <20130108173550.14072.qmail@stuge.se> Message-ID: Hi, Peter. Thank you for your reply. To answer your questions (marked by >> ) > Your quote is "cd d:" but your command is "cd d:/" and those are > different, so the above part is not very clear. Please clarify. I am discussing trying to sftp to a "d:/" drive letter specification, as opposed to a d: sub-directory. But the problem exists either way it is attempted, as far as i can see, whether it is "cd d:" or "cd d:/". > Why would a behavior change be acceptable? Any change that you make > must affect only Windows, and nothing else. I agree. The proposed change was #ifdef HAVE_CYGWIN, so it would only change existing behaviour under Cygwin. I was not intending anywhere to imply that existing behaviour needed changing on other platforms, I am only discussing the Cygwin environment. >> Stop right here. "d:" is *NOT* an absolute path on Windows systems. Sorry, I meant d:/ which is an absolute path under DOS or Windows, but it is not an absolute path under Cygwin. In a Cygwin shell, if you are in a directory with a d: sub-directory present, then if you like, you could specify "cd d:/" when referring to the d: sub-directory. The use of a trailing slash when referring to any directory, whether absolute or relative, is not forbidden on a UNIX file system. This is the whole problem with Cygwin on windows, there is an ambiguity possible when referring to any 2-character path specification that starts with a single alphabetic character (a-z), and the second character is a colon (:). Such a sub-directory name is ambiguous with a drive letter specification. Under Cygwin, the only way to know such an specification is referring to an absolute path is if it looks like an absolute path (i.e. is specified as d:/), and the absolute path (i.e. drive letter) actually exists! Thus the behaviour of the Cygwin cd command depends on the existence of what stuff it finds! It will cd to an existing d: sub-directory only if a d: drive does not exist. Thus "d:/" could be an absolute path or it could refer to a (relative path) sub-directory. This problem does not happen on UNIX, where an absolute path is indicated merely by the presence of the first character being a /., and a relative path on UNIX is any path that does NOT start with a slash. Since there is an existing way to specifically force an argument to be a relative path (by pre-pending a "./" to it, but there is no way to indicate something is really an absolute path under Cygwin, then a convention of some kind must be a applied. One convention that seems to make sense is if we have a 2-character "letter-then-colon" specification, such as either "d:" or "d:/" then the argument handler will look first for a drive specification, and only if it does not exist, then look for a sub-directory name d:. This is the existing Cygwin command-line behaviour. Since there is an ambigity possible on Cygwin, which does not occur on UNIX, then a choice must be made how to resolve it, and we have the precedence of the Cygwin command-line handler as a guide. If one really means to refer to a sub-directory named "d:", then they must use "./" in this case. As indicated in my original post, implementing the same behaviour as the Cygwin command-line handler would likely be preferable, but beyond my capabilities, I was only doing the research into the existing behaviours that I am able to do. Such a fix would likely involve the sftp-server as you indicate. However, it is the sftp-client code I found that is assuming that if a directory specification does not start with a / then it must be relative, which is only true on UNIX, and not under Cygwin, and this code would still have to be fixed in addition to the server side code. Rick ---------------------------------------- > Date: Tue, 8 Jan 2013 18:35:50 +0100 > From: peter at stuge.se > To: openssh-unix-dev at mindrot.org > Subject: Re: sftp "cd" command to drive letter under cygwin > > Rick Patterson wrote: >> When using sftp under cygwin, a "cd d:" attempt to change to the d: >> drive, results in the following: >> sftp> cd d:/ >> Couldn't canonicalise: No such file or directory. > > Your quote is "cd d:" but your command is "cd d:/" and those are > different, so the above part is not very clear. Please clarify. > > >> Since cygwin is supposed to support DOS paths as well as UNIX >> paths, and the lcd is working, I thought I'd take a look at it. I >> found the make_absolute function in sftp.c was assuming an absolute >> path starts with '/', but this is not true on Windows. I think >> the attached sftp.c.diff file is the fix, for your review, although >> there is a behavior change I'd like to discuss below. > > Why would a behavior change be acceptable? Any change that you make > must affect only Windows, and nothing else. > > >> Previously, under Cygwin, in sftp, "cd d:" would not work, unless >> there was a sub-directory in the current working directory that was >> named "d:", which is allowed on the UNIX file system, as ":" is an >> allowed file name character. With the proposed change, assuming >> you want to "cd to d:" (where d: is a drive specification, and >> therefore an absolute path), > > Stop right here. "d:" is *NOT* an absolute path on Windows systems. > > I'm sure you know that DOS and Windows both keep track of the current > working directory per drive. "d:" changes working drive, but does NOT > change current working directory either on the current driver or on d:. > > "d:\" and "d:/" are absolute paths. > > >> the cd now works to the absolute path "d:" thereby supporting DOS >> paths. However, it also changes the previous behavior, as "cd d:" >> will now not go to the sub-directory "d:" if it exists, unless it >> is qualified as "./d:" > > I can not understand why you would modify behavior for every other > platform as well. Isn't it absolutely obvious that whatever change > you do in order to improve this on Windows must have *NO* effect on > the vast majority of other operating systems that OpenSSH supports? > > >> A "d:" needs to be treated firstly as an absolute path before a >> sub-directory. > > On Cygwin, "d:" is a path relative to the current working directory > on drive d. Everywhere else, it is a path relative to the current > working directory. > > >> I agree a batter fix might be that "if d:" does not exist as a >> drive letter, but there is a "d:" sub-directory, then cd to the >> d: sub-directory. > > Absolutely not, in my opinion. You are proposing to add a heuristic > into the user interface. Sorry, but that is just horrible. > > >> I've tested the cd command under the Cygwin command line shell - it >> does appear to be able to conditionally cd to d: as a DOS drive if >> it exists, ignoring a d: sub-directory that exists. However, if >> x: does not exist as a drive letter, but does exist as a >> sub-directory then it does cd to x:. I believe an extra call from >> the sftp client to the sftp server would be required to do the >> conditional cd in sftp to be consistent with the Cygwin command >> line, but this would be beyond my abilities. > > I'd suggest to look at the Cygwin source code to find out how exactly > chdir() is implemented, and to make sftp-server implement the same > algorithm. The client shouldn't have to be involved in this at all. > (Unless Cygwin patches all shells to make multiple chdir() calls, but > I find that somewhat unlikely.) > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rick.patterson at hotmail.com Wed Jan 9 08:57:48 2013 From: rick.patterson at hotmail.com (Rick Patterson) Date: Tue, 8 Jan 2013 16:57:48 -0500 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: <20130108191309.GA12920@calimero.vinschen.de> References: , <20130108173550.14072.qmail@stuge.se>, <20130108191309.GA12920@calimero.vinschen.de> Message-ID: HI, Corinna.? > However, DOS paths are only barely supported. The right thing to do is > NOT to use DOS paths, but the equivalent POSIX path. This is also > documented in the User's Guide: > > http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 > I've seen that message before, and do not agree with it. Cygwin should make Windows easier for Windows developers, not harder by recommending they map all files to a different file system.?? Unfortunately, I think I'm about 10 years too late in this argument, and I don't really expect Cygwin would change at this point, but I would like to point out why I think it is a less than an ideal position to have taken. The Cygwin support for a POSIX file system is fine for those who wish or prefer to use it, and have control over all parts of their application, but to make a recommendation saying "if you don't use it you'll just get in trouble" was the wrong direction to take.? A better direction would have been:? "we fully support the DOS file system, but if you want to look and work like UNIX, we do that too!"? How can it be a strong position to "barely support" the normal access to the native file system of an operating system, and make it a second class citizen? A typical application is not just all Cygwin, but has to work with other existing applications and databases, which might only normally know about "Windows" files and "UNIX" files.? There's usually no support in other applications for "Windows machine but with POSIX file system". For example: in regards to your next comment: ?? >There's no reason to change anything. Don't use DOS paths in Cygwin applications. We don't have a "Cygwin" application.? We have a Windows application that if you wish to use commands from a UNIX subsystem (various ones are available) then that can be accommodated. For example, sftp is a typical third-party add-on Windows application.? Our application might run on a machine with no UNIX subsystem or on one with Cygwin, or one with some other UNIX utilities that include sftp.? If our application is configured to use sftp, and it sits on a Windows machine it can find "sftp" on, it assumes everything is okay, and generates a standard ftp batch transfer file, transferring windows files to other Windows and UNIX machines, using target location data fetched from a database.? The database might be used by any number of applications which are not Cygwin aware, so it is natural to put pat information in this database that reflect the filesystem for the operating system of the machine, and not what what this data might be mapped to if it is used via Cygwin. ?? What is even more complicated is now our application is supposed to know not just whether the local machine it is running on is using Cygwin, and so map local files to Cygdrive, but also whether the target machines has a Cygwin sftp on it, and if so, convert the path data written to the sftp batch files to a Cygdrive specification, suitable for the the target machine. ? sftp, a derivative of ftp, being one of the oldest and stradard TCP/IP applications, should not have a problem whereby it cannot find Windows files or directories when it is running on a Windows machine. Rick ---------------------------------------- > Date: Tue, 8 Jan 2013 20:13:09 +0100 > From: vinschen at redhat.com > To: openssh-unix-dev at mindrot.org > Subject: Re: sftp "cd" command to drive letter under cygwin > > On Jan 8 18:35, Peter Stuge wrote: > > Rick Patterson wrote: > > > When using sftp under cygwin, a "cd d:" attempt to change to the d: > > > drive, results in the following: > > > sftp> cd d:/ > > > Couldn't canonicalise: No such file or directory. > > > > Your quote is "cd d:" but your command is "cd d:/" and those are > > different, so the above part is not very clear. Please clarify. > > > > > > > Since cygwin is supposed to support DOS paths as well as UNIX > > > paths, and the lcd is working, I thought I'd take a look at it. I > > > found the make_absolute function in sftp.c was assuming an absolute > > > path starts with '/', but this is not true on Windows. I think > > > the attached sftp.c.diff file is the fix, for your review, although > > > there is a behavior change I'd like to discuss below. > > > > Why would a behavior change be acceptable? Any change that you make > > must affect only Windows, and nothing else. > > > > > > > Previously, under Cygwin, in sftp, "cd d:" would not work, unless > > > there was a sub-directory in the current working directory that was > > > named "d:", which is allowed on the UNIX file system, as ":" is an > > > allowed file name character. With the proposed change, assuming > > > you want to "cd to d:" (where d: is a drive specification, and > > > therefore an absolute path), > > > > Stop right here. "d:" is *NOT* an absolute path on Windows systems. > > > > I'm sure you know that DOS and Windows both keep track of the current > > working directory per drive. "d:" changes working drive, but does NOT > > change current working directory either on the current driver or on d:. > > > > "d:\" and "d:/" are absolute paths. > > This isn't correct. Cygwin doesn't follow the lead of the CMD shell > here. As a POSIX layer it only keeps track of a single CWD, in POSIX > and native NT notation. Therefore, on Cygwin, d: is an absolute path, > too. > > However, DOS paths are only barely supported. The right thing to do is > NOT to use DOS paths, but the equivalent POSIX path. This is also > documented in the User's Guide: > > http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 > > > I'd suggest to look at the Cygwin source code to find out how exactly > > chdir() is implemented, and to make sftp-server implement the same > > algorithm. The client shouldn't have to be involved in this at all. > > (Unless Cygwin patches all shells to make multiple chdir() calls, but > > I find that somewhat unlikely.) > > There's no reason to change anything. Don't use DOS paths in Cygwin > applications. > > > Corinna > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From peter at stuge.se Wed Jan 9 14:40:20 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 9 Jan 2013 04:40:20 +0100 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: References: <20130108191309.GA12920@calimero.vinschen.de> Message-ID: <20130109034020.2417.qmail@stuge.se> Rick Patterson wrote: > Cygwin should make Windows easier for Windows developers Corinna frequently gets to repeat the truth, so I'll help this time: Cygwin is not Windows. > We don't have a "Cygwin" application.? We have a Windows application Ok. > that if you wish to use commands from a UNIX subsystem (various > ones are available) then that can be accommodated. So far so good. But keep in mind that you're still a Windows application. > For example, sftp is a typical third-party add-on Windows > application.? Our application might run on a machine with no > UNIX subsystem or on one with Cygwin, or one with some other > UNIX utilities that include sftp. Sure. And you will quite likely need to have different code for each different case, and in addition you will need to have different code for every type of SFTP destination for each different case. > If our application is configured to use sftp, and it sits on a > Windows machine it can find "sftp" on, it assumes everything is > okay, and generates a standard ftp batch transfer file, > transferring windows files to other Windows and UNIX machines, > using target location data fetched from a database. So actually you only support one specific implementation of "sftp" because you rely on it understanding the OpenSSH sftp batch file format? > The database might be used by any number of applications which are > not Cygwin aware, so it is natural to put pat information in this > database that reflect the filesystem for the operating system of > the machine, and not what what this data might be mapped to if it > is used via Cygwin. ?? What is even more complicated is now our > application is supposed to know not just whether the local machine > it is running on is using Cygwin, and so map local files to > Cygdrive, but also whether the target machines has a Cygwin sftp on > it, and if so, convert the path data written to the sftp batch > files to a Cygdrive specification, suitable for the the target > machine. That's exactly right. If you want to handle all cases, that's what you'll have to do. > sftp, a derivative of ftp, sftp is a SSH version 2 subsystem protocol and has nothing at all to do with FTP, except that both are protocols for transfering files. :) > being one of the oldest and stradard TCP/IP applications, should > not have a problem whereby it cannot find Windows files or > directories when it is running on a Windows machine. No matter what protocol you look at, successful implementation can certainly require consideration of remote endpoint system properties. //Peter From vinschen at redhat.com Wed Jan 9 20:36:26 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 9 Jan 2013 10:36:26 +0100 Subject: sftp "cd" command to drive letter under cygwin In-Reply-To: References: <20130108173550.14072.qmail@stuge.se> <20130108191309.GA12920@calimero.vinschen.de> Message-ID: <20130109093626.GA20412@calimero.vinschen.de> On Jan 8 16:57, Rick Patterson wrote: > HI, Corinna.? > > > However, DOS paths are only barely supported. The right thing to do is > > NOT to use DOS paths, but the equivalent POSIX path. This is also > > documented in the User's Guide: > > > > http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 > > > > I've seen that message before, and do not agree with it. Cygwin should > make Windows easier for Windows developers, not harder by recommending > they map all files to a different file system. I'm sorry if you don't agree to the project goals, but that's how they are. Other projects have other goals. What you are asking for is supposed to be supported by a native sftp implementation like WinSCP. > [...] > A typical application is not just all Cygwin, but has to work with > other existing applications and databases, which might only normally > know about "Windows" files and "UNIX" files.? There's usually no > support in other applications for "Windows machine but with POSIX file > system". You're mixing apples and oranges. Cygwin is a POSIX emulation layer and thus clearly dedicated to the POSIX side of things. However, just because Cygwin applications should use POSIX paths doesn't mean it's impossible to run non-Cygwin Windows applications from a Cygwin bash or any other Cygwin application. And there *are* officially supported ways to convert from POSIX to DOS paths and vice versa: http://cygwin.com/cygwin-ug-net/using-utils.html#cygpath http://cygwin.com/cygwin-api/func-cygwin-conv-path.html > For example: in regards to your next comment: > > ?? >There's no reason to change anything. Don't use DOS paths in Cygwin applications. > > We don't have a "Cygwin" application.? We have a Windows application Yes, you have a Cygwin application. You can choose to run the Cygwin sftp or a native Windows sftp. If you use Cygwin sftp, you're in POSIX land. If you want to remote control Cygwin sftp from a native Windows environment, consider using cygpath. > that if you wish to use commands from a UNIX subsystem (various ones > are available) then that can be accommodated. For example, sftp is a > typical third-party add-on Windows application.? Our application might No, it's not. Cygwin sftp is cleanrly a Cygwin application. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Thu Jan 10 19:35:59 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Jan 2013 19:35:59 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: <20130107132713.GN5006@acooke.org> References: <20121121184930.GX11406@acooke.org> <20130107132713.GN5006@acooke.org> Message-ID: On Mon, 7 Jan 2013, andrew cooke wrote: > > Just FYI, this patch (host keys via PKCS11) doesn't appear to call > C_CloseSession. Andrew I don't think we do for elsewhere either :| From hussainakbar at gmail.com Thu Jan 10 22:35:48 2013 From: hussainakbar at gmail.com (Hussain Akbar) Date: Thu, 10 Jan 2013 16:35:48 +0500 Subject: SSH from within OpenSSH Message-ID: This is a request for a How-To I need to SSH from my Windows 7 laptop to several Linux machines that are inside a secondary VPN. To explain: I have a network (Call it LAN A), containing a few Windows 2K servers, that is protected by a VPN. That network connects to another one (call it LAN B), that has a few Linux server, over a separate site-to-site VPN. >From outside (here) I have no access to LAN B as it only allows connections from selected servers of LAN A. I normally initiate a VPN session to LAN A, use Remote Desktop to open a session on one of the W2K machines on LAN A, then use PuTTY to connect to the desired Linux server. Today, I tried OpenSSH. I installed it on the W2K server in LAN A. Then I used PuTTY from my Laptop to W2K. Got the DOS prompt. One thing I notice is that if I press any cursor key, W2K takes that to be a control character. i.e. Pressing cursor and hitting enter gives and error: *' command not found*. Yes, there is a single quote at the start. Next, I used plink to connect to a Linux server on LAN B. Issues: At signin, the last character seems to get missed. So if I type "root" as userid I get prompted for the password for "roo", so I typed "rootA". Same thing with the password, so I had to type and extra character after it to sign in. The cursor key still doesn't work, or works intermittently. e.g. in VIM I have to press one cursor key and then hit the space bar, etc. There appears to be some ANSI conversion going on and on the Linux command line I get messages such as &0a not found. Sometimes it gets stuck in a loop printing such messages by the hundred. Help? From djm at mindrot.org Thu Jan 10 22:50:38 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Jan 2013 22:50:38 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> <20130107132713.GN5006@acooke.org> Message-ID: On Thu, 10 Jan 2013, Damien Miller wrote: > On Mon, 7 Jan 2013, andrew cooke wrote: > > > > > Just FYI, this patch (host keys via PKCS11) doesn't appear to call > > C_CloseSession. Andrew > > I don't think we do for elsewhere either :| Markus points out I'm totally wrong - ignore this. We do call it in most places. -d From keisial at gmail.com Fri Jan 11 09:26:32 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 10 Jan 2013 23:26:32 +0100 Subject: SSH from within OpenSSH In-Reply-To: References: Message-ID: <50EF4018.7060505@gmail.com> On 10/01/13 12:35, Hussain Akbar wrote: > Today, I tried OpenSSH. I installed it on the W2K server in LAN A. You installed the OpenSSH ssh *server* ? Where did you get it from? > Then I used PuTTY from my Laptop to W2K. Got the DOS prompt. One thing I > notice is that if I press any cursor key, W2K takes that to be a control > character. i.e. Pressing cursor and hitting enter gives and error: *' > command not found*. Yes, there is a single quote at the start. Yes, something seems to be wrong. Have you played with the different options on PuTTY config? You don't have W2000 in an odd locale, do you? > Next, I used plink to connect to a Linux server on LAN B. > > Issues: > At signin, the last character seems to get missed. So if I type "root" as > userid I get prompted for the password for "roo", so I typed "rootA". Same > thing with the password, so I had to type and extra character after it to > sign in. Does it happen if you directly run plink from the remote desktop? That would isolate it to the running of commands on W2K. > The cursor key still doesn't work, or works intermittently. e.g. in VIM I > have to press one cursor key and then hit the space bar, etc. > > There appears to be some ANSI conversion going on and on the Linux command > line I get messages such as &0a not found. Sometimes it gets stuck in a > loop printing such messages by the hundred. > > Help? As a workaround, you could make a ssh tunnel (SSH/Tunnels). That way the W2000 machine won't be processing your commands in any way (actually, it could even have a keylogger installed, and it won't matter at all). Still, it would be nice that it worked (even though Windows 2000 is well beyond its End Of Life...). From imorgan at nas.nasa.gov Fri Jan 11 11:12:39 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 10 Jan 2013 16:12:39 -0800 Subject: ssh / scp slow on 10GBE In-Reply-To: References: <50E4B4BA.7050906@profihost.ag> <20130103191907.GB3451@linux124.nas.nasa.gov> <50E6C0AE.9050104@profihost.ag> <20130104190827.GA12927@linux124.nas.nasa.gov> <50E9C9BD.6050000@profihost.ag> <50EAA66B.2060406@oracle.com> Message-ID: <20130111001239.GA5627@linux124.nas.nasa.gov> On Mon, Jan 07, 2013 at 04:57:01 -0600, Damien Miller wrote: > On Mon, 7 Jan 2013, Tomas Kuthan wrote: > > > >>Part of the gap between encryption speed and the dd measurement can be > > >>accounted to checksumming, some to initial key-exchange and rekeying. > > >>The gap still feels quite wide though. > > > Now it's 400MB/s using ssh and 1230MB/s when using a direct TCP connection. > > > > Well, you certainly won't get anything faster than your 700 MB of > > openssl aes speed results. You cannot transmit data faster, than you > > encrypt them. And even this upper bound is not reachable, because of > > checksumming overhead. > > Right: if you are using AES and umac-64 as your MAC then you are actually > invoking AES twice as umac-64 uses AES internally. > > > There is a potential in enhancing OpenSSH to do some tasks in parallel. > > MACs and encryption could be done at the same time. Or, for some modes > > of encryption, counters can be pre-computed in advance. But in the past > > OpenSSH developers expressed strongly against threads... > > Yeah, we do don't want to go there (threads in OpenSSH). You might be > able to make an OpenSSL engine implementation that manages it all on the > OpenSSL side. > > Alternately, we are considering adding support for AES-GCM which is very > fast on recent Intel CPUs and probably slightly faster than AES+umac-64 > everywhere. > > -d Apparently, it was more than just "considering." :-) Nice to see the addition of AES-GCM in recent snapshots! Thanks -- Iain Morgan From hussainakbar at gmail.com Fri Jan 11 16:54:47 2013 From: hussainakbar at gmail.com (Hussain Akbar) Date: Fri, 11 Jan 2013 10:54:47 +0500 Subject: SSH from within OpenSSH In-Reply-To: <50EF4018.7060505@gmail.com> References: <50EF4018.7060505@gmail.com> Message-ID: Angel See my replies below: On Fri, Jan 11, 2013 at 3:26 AM, ?ngel Gonz?lez wrote: > On 10/01/13 12:35, Hussain Akbar wrote: > > Today, I tried OpenSSH. I installed it on the W2K server in LAN A. > You installed the OpenSSH ssh *server* ? Where did you get it from? > > I downloaded it from SourceForge. Don't recall precisely where, but I think it was from http://sourceforge.net/projects/sshwindows/files/OpenSSH%20for%20Windows%20-%20Release/ > > Then I used PuTTY from my Laptop to W2K. Got the DOS prompt. One thing I > > notice is that if I press any cursor key, W2K takes that to be a control > > character. i.e. Pressing cursor and hitting enter gives and error: *' > > command not found*. Yes, there is a single quote at the start. > Yes, something seems to be wrong. Have you played with the different > options on PuTTY config? You don't have W2000 in an odd locale, do you? > The Windows server is configured as US English. > > > Next, I used plink to connect to a Linux server on LAN B. > > > > Issues: > > At signin, the last character seems to get missed. So if I type "root" as > > userid I get prompted for the password for "roo", so I typed "rootA". > Same > > thing with the password, so I had to type and extra character after it to > > sign in. > Does it happen if you directly run plink from the remote desktop? > That would isolate it to the running of commands on W2K. > Yes, I am running plink from the laptop. > > > The cursor key still doesn't work, or works intermittently. e.g. in VIM I > > have to press one cursor key and then hit the space bar, etc. > > > > There appears to be some ANSI conversion going on and on the Linux > command > > line I get messages such as &0a not found. Sometimes it gets stuck in a > > loop printing such messages by the hundred. > > > > Help? > As a workaround, you could make a ssh tunnel (SSH/Tunnels). That way the > W2000 machine won't be processing your commands in any way (actually, > it could even have a keylogger installed, and it won't matter at all). > > My first try was to make an SSH tunnel. Have been trying all sort of combinations in PuTTY but can't figure out how. The ultimate aim would be to not be forced to get an interactive session on the Windows server at all but go directly to the Linux server. I tried what things I could in PuTTY's tunnel options, but no joy so far. I posted this to various newsgroups but from the feedback I've been getting, most people say it can't be done. > Still, it would be nice that it worked (even though Windows 2000 is well > beyond its End Of Life...). > > Actually, not Windows 2000, but Windows 2003 Server. From mouring at eviladmin.org Fri Jan 11 18:00:25 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 11 Jan 2013 01:00:25 -0600 Subject: SSH from within OpenSSH In-Reply-To: References: <50EF4018.7060505@gmail.com> Message-ID: <61384F9D-E914-4C1B-A823-875EBB01D5D1@eviladmin.org> You consider using socks proxy? On your linux box do: $ ssh -D 8080 user at win2k3server Then in another window on the same linux box: $ ssh -o ProxyCommand='socat - SOCKS4A:win2kserver:%h:21,socksport=8080' LANB-server using: http://www.dest-unreach.org/socat/ as your ProxyCommand ? I know OpenSSH supports SOCKS5 (use it all the time), but not sure about 4A, and my memory of that time is fuzzy around that conversation. Which means you may have to use SOCKS4 and use IP address for the LANB machines or /etc/hosts files or ~/.ssh/config files to clean it up and define the machines. e..g host LANB-server ProxyCommand='socat - SOCKS4A:win2kserver:%h:21,socksport=8080' HostName IP.OF.HOST Note this is completely untested by me.. I just know a few others have done things much like this in my circle. - Ben From dtucker at zip.com.au Fri Jan 11 19:56:09 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Jan 2013 19:56:09 +1100 Subject: SSH from within OpenSSH In-Reply-To: <61384F9D-E914-4C1B-A823-875EBB01D5D1@eviladmin.org> References: <50EF4018.7060505@gmail.com> <61384F9D-E914-4C1B-A823-875EBB01D5D1@eviladmin.org> Message-ID: <20130111085238.GA20540@gate.dtucker.net> On Fri, Jan 11, 2013 at 01:00:25AM -0600, Ben Lindstrom wrote: > > You consider using socks proxy? > > On your linux box do: > > $ ssh -D 8080 user at win2k3server > Then in another window on the same linux box: > $ ssh -o ProxyCommand='socat - SOCKS4A:win2kserver:%h:21,socksport=8080' LANB-server If you're doing things like that you can now use ssh -W (aka "netcat mode") so you don't need external dependencies or listening ports: ssh -o "ProxyCommand ssh -W %h:%p user at win2k3server" LANB-server or the equivalent entry in ~/ssh/config. -- 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 hussainakbar at gmail.com Fri Jan 11 21:07:48 2013 From: hussainakbar at gmail.com (Hussain Akbar) Date: Fri, 11 Jan 2013 15:07:48 +0500 Subject: SSH from within OpenSSH In-Reply-To: <61384F9D-E914-4C1B-A823-875EBB01D5D1@eviladmin.org> References: <50EF4018.7060505@gmail.com> <61384F9D-E914-4C1B-A823-875EBB01D5D1@eviladmin.org> Message-ID: Ben Hmm... it appears to me that what you say would work but not in my case; I don't want to SSH from linux to W2K3. Instead, I want to SSH from Win7 laptop to Linux via a W2K3 server which is in the middle. Thx Hussain On Fri, Jan 11, 2013 at 12:00 PM, Ben Lindstrom wrote: > > You consider using socks proxy? > > On your linux box do: > > $ ssh -D 8080 user at win2k3server > > Then in another window on the same linux box: > > $ ssh -o ProxyCommand='socat - SOCKS4A:win2kserver:%h:21,socksport=8080' > LANB-server > > using: http://www.dest-unreach.org/socat/ as your ProxyCommand ? > > I know OpenSSH supports SOCKS5 (use it all the time), but not sure about > 4A, and my memory of that time is fuzzy around that conversation. Which > means you may have to use SOCKS4 and use IP address for the LANB machines > or /etc/hosts files or ~/.ssh/config files to clean it up and define the > machines. > > e..g > > host LANB-server > ProxyCommand='socat - SOCKS4A:win2kserver:%h:21,socksport=8080' > HostName IP.OF.HOST > > > Note this is completely untested by me.. I just know a few others have > done things much like this in my circle. > > - Ben From keisial at gmail.com Fri Jan 11 22:23:26 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 11 Jan 2013 12:23:26 +0100 Subject: SSH from within OpenSSH In-Reply-To: References: <50EF4018.7060505@gmail.com> Message-ID: <50EFF62E.70700@gmail.com> On 11/01/13 06:54, Hussain Akbar wrote: > My first try was to make an SSH tunnel. Have been trying all sort of > combinations in PuTTY but can't figure out how. The ultimate aim would > be to not be forced to get an interactive session on the Windows > server at all but go directly to the Linux server. > > I tried what things I could in PuTTY's tunnel options, but no joy so far. > > I posted this to various newsgroups but from the feedback I've been > getting, most people say it can't be done. In PuTTY go to Connection/SSH/Tunnels Source port: 1234 Destination: 1.2.3.4:22 Press Add Connect to W2K as usual. Ignore its console. Open a new PuTTY instance, but connect to 127.0.0.1 on port 1234 You will get a connection to the Linux server. (Replace 1.2.3.4 with the hostname/ip of your Linux server, 1234 can be changed to an arbitrary port) I don't think you can completely skip the console allocation with PuTTY.exe, but you can do it with plink: plink -N -L 1234:1.2.3.4:22 username at 5.6.7.8 (replace 5.6.7.8 with the hostname/ip of the W2K server) From hussainakbar at gmail.com Fri Jan 11 22:44:06 2013 From: hussainakbar at gmail.com (Hussain Akbar) Date: Fri, 11 Jan 2013 16:44:06 +0500 Subject: SSH from within OpenSSH In-Reply-To: <50EFF62E.70700@gmail.com> References: <50EF4018.7060505@gmail.com> <50EFF62E.70700@gmail.com> Message-ID: Man, that sounds completely like magic as to how the three systems would figure out what I am trying to do ;} Thanks. Shall try this and let you know of the result. On Fri, Jan 11, 2013 at 4:23 PM, ?ngel Gonz?lez wrote: > On 11/01/13 06:54, Hussain Akbar wrote: > > My first try was to make an SSH tunnel. Have been trying all sort of > > combinations in PuTTY but can't figure out how. The ultimate aim would > > be to not be forced to get an interactive session on the Windows > > server at all but go directly to the Linux server. > > > > I tried what things I could in PuTTY's tunnel options, but no joy so far. > > > > I posted this to various newsgroups but from the feedback I've been > > getting, most people say it can't be done. > > In PuTTY go to Connection/SSH/Tunnels > Source port: 1234 > Destination: 1.2.3.4:22 > Press Add > > Connect to W2K as usual. Ignore its console. > > Open a new PuTTY instance, but connect to 127.0.0.1 on port 1234 > You will get a connection to the Linux server. > > (Replace 1.2.3.4 with the hostname/ip of your Linux server, 1234 can be > changed to an arbitrary port) > > I don't think you can completely skip the console allocation with > PuTTY.exe, but you can do it with plink: > plink -N -L 1234:1.2.3.4:22 username at 5.6.7.8 > (replace 5.6.7.8 with the hostname/ip of the W2K server) > > From kocar at hotmail.com Fri Jan 11 23:05:49 2013 From: kocar at hotmail.com (Jose Ortega) Date: Fri, 11 Jan 2013 13:05:49 +0100 Subject: OpenSSH Overwrite path Message-ID: Good news, your program CYGWIN Openssh has overwrite my %PATH% in a Prudcution W2003 Server. Many thanks for the problems in my job. From dtucker at zip.com.au Fri Jan 11 23:51:18 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Jan 2013 23:51:18 +1100 Subject: OpenSSH Overwrite path In-Reply-To: References: Message-ID: On Fri, Jan 11, 2013 at 11:05 PM, Jose Ortega wrote: > Good news, your program CYGWIN Openssh has overwrite my %PATH% in a Prudcution W2003 Server. > Many thanks for the problems in my job. If you're referring to the binary package of openssh at http://sshwindows.sourceforge.net/ then that is not supplied, endorsed or supported by the openssh team. The binary package is extremely old and I wish they'd take it down. I'd suggest you direct your complaints to the correct forum, however I do not no what that would be (the list referred to by http://sshwindows.sourceforge.net/support/ no longer exists). -- 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 keisial at gmail.com Sat Jan 12 00:20:50 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 11 Jan 2013 14:20:50 +0100 Subject: OpenSSH Overwrite path In-Reply-To: References: Message-ID: <50F011B2.5080102@gmail.com> El 11/01/13 13:05, Jose Ortega escribi?: > Good news, your program CYGWIN Openssh has overwrite my %PATH% in a Prudcution W2003 Server. > Many thanks for the problems in my job. Why are you complaining to the OpenSSH project instead of Cygwin? http://www.cygwin.com/ (I think it does ask before adding itself -not replacing- to the system path, but don't take my word for it...) From vinschen at redhat.com Sat Jan 12 01:19:36 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 11 Jan 2013 15:19:36 +0100 Subject: OpenSSH Overwrite path In-Reply-To: <50F011B2.5080102@gmail.com> References: <50F011B2.5080102@gmail.com> Message-ID: <20130111141936.GB29574@calimero.vinschen.de> On Jan 11 14:20, ?ngel Gonz?lez wrote: > El 11/01/13 13:05, Jose Ortega escribi?: > > Good news, your program CYGWIN Openssh has overwrite my %PATH% in a Prudcution W2003 Server. > > Many thanks for the problems in my job. > Why are you complaining to the OpenSSH project instead of Cygwin? > http://www.cygwin.com/ > > (I think it does ask before adding itself -not replacing- to the system > path, but don't take my word for it...) Cywin doesn't replace the Windows system or user $PATH at all. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From hussainakbar at gmail.com Sat Jan 12 01:41:53 2013 From: hussainakbar at gmail.com (Hussain Akbar) Date: Fri, 11 Jan 2013 19:41:53 +0500 Subject: SSH from within OpenSSH In-Reply-To: <50EFF62E.70700@gmail.com> References: <50EF4018.7060505@gmail.com> <50EFF62E.70700@gmail.com> Message-ID: Angel Your are one **** smart fellow. You have no idea how smart. Really brilliant. Thanks a million. The PuTTY solution works perfectly. All cursor keys work. The plink solution didn't work; it gave me a session on the W2K3 server instead of Linux. Or did you mean to run plink first? In case case, problem solved. Thanks again Hussain On Fri, Jan 11, 2013 at 4:23 PM, ?ngel Gonz?lez wrote: > On 11/01/13 06:54, Hussain Akbar wrote: > > My first try was to make an SSH tunnel. Have been trying all sort of > > combinations in PuTTY but can't figure out how. The ultimate aim would > > be to not be forced to get an interactive session on the Windows > > server at all but go directly to the Linux server. > > > > I tried what things I could in PuTTY's tunnel options, but no joy so far. > > > > I posted this to various newsgroups but from the feedback I've been > > getting, most people say it can't be done. > > In PuTTY go to Connection/SSH/Tunnels > Source port: 1234 > Destination: 1.2.3.4:22 > Press Add > > Connect to W2K as usual. Ignore its console. > > Open a new PuTTY instance, but connect to 127.0.0.1 on port 1234 > You will get a connection to the Linux server. > > (Replace 1.2.3.4 with the hostname/ip of your Linux server, 1234 can be > changed to an arbitrary port) > > I don't think you can completely skip the console allocation with > PuTTY.exe, but you can do it with plink: > plink -N -L 1234:1.2.3.4:22 username at 5.6.7.8 > (replace 5.6.7.8 with the hostname/ip of the W2K server) > > From keisial at gmail.com Sat Jan 12 02:05:07 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 11 Jan 2013 16:05:07 +0100 Subject: SSH from within OpenSSH In-Reply-To: References: <50EF4018.7060505@gmail.com> <50EFF62E.70700@gmail.com> Message-ID: <50F02A23.4040700@gmail.com> On 11/01/13 15:41, Hussain Akbar wrote: > Angel > > Your are one **** smart fellow. You have no idea how smart. Really > brilliant. Thanks. It's odd that you were said it wasn't possible. > Thanks a million. The PuTTY solution works perfectly. All cursor keys > work. > > The plink solution didn't work; it gave me a session on the W2K3 > server instead of Linux. Or did you mean to run plink first? I was proposing to replace the first PuTTY instance (the one you only use for tunneling) with that plink command. You would still need another putty to connect to the real server. It probably explained it too fast. > In case case, problem solved. > > Thanks again > Hussain You're welcome. From djm at mindrot.org Sat Jan 12 22:14:19 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 12 Jan 2013 22:14:19 +1100 (EST) Subject: OpenSSH Overwrite path In-Reply-To: References: Message-ID: On Fri, 11 Jan 2013, Jose Ortega wrote: > Good news, your program CYGWIN Openssh has overwrite my %PATH% in a > Prudcution W2003 Server. > Many thanks for the problems in my job. If you are unhappy with OpenSSH we'll gladly refund whatever money you paid us for it. -d From gert at greenie.muc.de Sun Jan 13 07:10:02 2013 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 12 Jan 2013 21:10:02 +0100 Subject: OpenSSH Overwrite path In-Reply-To: <50F011B2.5080102@gmail.com> References: <50F011B2.5080102@gmail.com> Message-ID: <20130112201001.GG22465@greenie.muc.de> Hi, On Fri, Jan 11, 2013 at 02:20:50PM +0100, ?ngel Gonz?lez wrote: > El 11/01/13 13:05, Jose Ortega escribi?: > > Good news, your program CYGWIN Openssh has overwrite my %PATH% in a Prudcution W2003 Server. > > Many thanks for the problems in my job. > Why are you complaining to the OpenSSH project instead of Cygwin? > http://www.cygwin.com/ > > (I think it does ask before adding itself -not replacing- to the system > path, but don't take my word for it...) One of the issues we ran into with the OpenVPN NSIS installer: on systems with a PATH of more than 1024 bytes, the installer's buffer is not big enough, and the path gets replaced, instead of appended to. To fix this, you need to recompile makensis with different buffer settings... (This has nothing to do with openssh-*unix*-dev, of course, but it might help whoever packaged that binary to avoid this particular trap) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From shogun147 at gmail.com Tue Jan 15 02:36:26 2013 From: shogun147 at gmail.com (Katsumoto san) Date: Mon, 14 Jan 2013 17:36:26 +0200 Subject: AuthorizedKeysCommand Message-ID: Hi there, We could set AuthorizedKeysCommand script, this will allow only to replace authorized_keys file with keys stored in a database... But why this command is so limited? Why i can't just set a command script which will get a username and public key as arguments and let him do it's own authorization?? I think this will allow for much more powerful tricks. For example do to an database lookup with keys to identify and authorize or deny access and so on... So is this so difficult to do? What do you all think about this? Thanks. From dkg at fifthhorseman.net Tue Jan 15 03:22:44 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Jan 2013 11:22:44 -0500 Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: <50F430D4.9060407@fifthhorseman.net> On 01/14/2013 10:36 AM, Katsumoto san wrote: > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? It sounds to me like you're proposing a different interface than the current AuthorizedKeysCommand -- the current interface maps quite cleanly to the AuthorizedKeysFile, and can be processed in a similar way by ssh (it's just reading the list of authorized keys from a different kind of file descriptor). What you're proposing sounds rather different (but i agree it could be useful). It's more of a KeyAuthorizationCommand (since it takes a single key and decides whether it is authorized) than an AuthorizedKeysCommand. But note that an ssh client can offer several keys to the ssh server [0] to see which ones might be acceptable. So the command you describe might need to be invoked several times per attempted connection. Maybe you could propose a concrete specification for what you want? How would the public key and user account be structured as arguments to the command? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... Note that the current API can still do a database lookup by the user account, as long as the database is able to enumerate the keys that are acceptable for authorizing access. --dkg [0] https://tools.ietf.org/html/rfc4252#section-7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From bostjan at a2o.si Tue Jan 15 04:00:59 2013 From: bostjan at a2o.si (Bostjan Skufca) Date: Mon, 14 Jan 2013 18:00:59 +0100 Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: Seems very useful. Implementation-wise I would not exclude AuthorizedKeysFile if AuthorizedKeysCommand was present, because if script will be connecting to external services which mail fail or hang, one still needs access to machine in case of emergency. In this respect, execution of external command should be time-limited to avoid locking admin out of the system in troubled times. b. On 14 January 2013 16:36, Katsumoto san wrote: > Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... > > So is this so difficult to do? What do you all think about this? > > Thanks. > _______________________________________________ > 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 Jan 15 05:55:48 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 14 Jan 2013 10:55:48 -0800 Subject: Inconsisten declaration of ssh_aes_ctr_iv() Message-ID: <20130114185547.GA3584@linux124.nas.nasa.gov> Hi, The 20130110 snapshot fails to build against OpenSSL 0.9.8 and 1.0.0 with the following error: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fno-builtin-memset -fstack-protector-all -I. -I. -DSSHDIR=\"/tmp/foo/etc\" -D_PATH_SSH_PROGRAM=\"/tmp/foo/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/tmp/foo/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/tmp/foo/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/tmp/foo/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/tmp/foo/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c cipher-ctr.c cipher-ctr.c:38: error: conflicting types for ?ssh_aes_ctr_iv? openbsd-compat/openssl-compat.h:71: note: previous declaration of ?ssh_aes_ctr_iv? was here cipher-ctr.c:117: error: conflicting types for ?ssh_aes_ctr_iv? openbsd-compat/openssl-compat.h:71: note: previous declaration of ?ssh_aes_ctr_iv? was here cipher-ctr.c: In function ?evp_aes_128_ctr?: cipher-ctr.c:141: warning: assignment from incompatible pointer type make: *** [cipher-ctr.o] Error 1 The following trivial patch addresses the compilation error, but does not address an the incompatible pointer warning which is encountered at line 141. (Note that there are similar warnings with cipher-bf1.c and cipher-3des.c.) Index: openbsd-compat/openssl-compat.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/openssl-compat.h,v retrieving revision 1.21 diff -u -r1.21 openssl-compat.h --- openbsd-compat/openssl-compat.h 9 Jan 2013 05:42:49 -0000 1.21 +++ openbsd-compat/openssl-compat.h 14 Jan 2013 18:39:27 -0000 @@ -68,7 +68,7 @@ #define EVP_aes_192_ctr evp_aes_128_ctr #define EVP_aes_256_ctr evp_aes_128_ctr extern const EVP_CIPHER *evp_aes_128_ctr(void); -extern void ssh_aes_ctr_iv(EVP_CIPHER_CTX *, int, u_char *, u_int); +extern void ssh_aes_ctr_iv(EVP_CIPHER_CTX *, int, u_char *, size_t); #endif /* Avoid some #ifdef. Code that uses these is unreachable without GCM */ -- Iain Morgan From imorgan at nas.nasa.gov Tue Jan 15 06:22:36 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 14 Jan 2013 11:22:36 -0800 Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: <20130114192236.GB3584@linux124.nas.nasa.gov> On Mon, Jan 14, 2013 at 09:36:26 -0600, Katsumoto san wrote: > Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... > > So is this so difficult to do? What do you all think about this? > I believe the intent was to minimize the risks by keeping the implementation simple. However, you can embed some flexibility either in the command which you invoke or, potentiall, in the repository used to store the keys. I don't quite see the advantage of the approach that you are suggesting. Could you elaborate on it a bit? What sort of "tricks" are you thinking of? -- Iain Morgan From djm at mindrot.org Tue Jan 15 08:15:43 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Jan 2013 08:15:43 +1100 (EST) Subject: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: <20130114185547.GA3584@linux124.nas.nasa.gov> References: <20130114185547.GA3584@linux124.nas.nasa.gov> Message-ID: On Mon, 14 Jan 2013, Iain Morgan wrote: > Hi, > > The 20130110 snapshot fails to build against OpenSSL 0.9.8 and 1.0.0 > with the following error: ... Try this: Index: cipher-aes.c =================================================================== RCS file: /var/cvs/openssh/cipher-aes.c,v retrieving revision 1.9 diff -u -p -r1.9 cipher-aes.c --- cipher-aes.c 7 Oct 2010 11:06:42 -0000 1.9 +++ cipher-aes.c 14 Jan 2013 21:14:23 -0000 @@ -46,9 +46,6 @@ struct ssh_rijndael_ctx u_char r_iv[RIJNDAEL_BLOCKSIZE]; }; -const EVP_CIPHER * evp_rijndael(void); -void ssh_rijndael_iv(EVP_CIPHER_CTX *, int, u_char *, u_int); - static int ssh_rijndael_init(EVP_CIPHER_CTX *ctx, const u_char *key, const u_char *iv, int enc) Index: cipher-ctr.c =================================================================== RCS file: /var/cvs/openssh/cipher-ctr.c,v retrieving revision 1.16 diff -u -p -r1.16 cipher-ctr.c --- cipher-ctr.c 12 Dec 2012 21:18:56 -0000 1.16 +++ cipher-ctr.c 14 Jan 2013 21:13:03 -0000 @@ -34,9 +34,6 @@ #include #endif -const EVP_CIPHER *evp_aes_128_ctr(void); -void ssh_aes_ctr_iv(EVP_CIPHER_CTX *, int, u_char *, size_t); - struct ssh_aes_ctr_ctx { AES_KEY aes_ctx; Index: openbsd-compat/openssl-compat.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/openssl-compat.h,v retrieving revision 1.21 diff -u -p -r1.21 openssl-compat.h --- openbsd-compat/openssl-compat.h 9 Jan 2013 05:42:49 -0000 1.21 +++ openbsd-compat/openssl-compat.h 14 Jan 2013 21:14:34 -0000 @@ -59,16 +59,16 @@ # define EVP_aes_128_cbc evp_rijndael # define EVP_aes_192_cbc evp_rijndael # define EVP_aes_256_cbc evp_rijndael -extern const EVP_CIPHER *evp_rijndael(void); -extern void ssh_rijndael_iv(EVP_CIPHER_CTX *, int, u_char *, u_int); +const EVP_CIPHER *evp_rijndael(void); +void ssh_rijndael_iv(EVP_CIPHER_CTX *, int, u_char *, u_int); #endif #ifndef OPENSSL_HAVE_EVPCTR #define EVP_aes_128_ctr evp_aes_128_ctr #define EVP_aes_192_ctr evp_aes_128_ctr #define EVP_aes_256_ctr evp_aes_128_ctr -extern const EVP_CIPHER *evp_aes_128_ctr(void); -extern void ssh_aes_ctr_iv(EVP_CIPHER_CTX *, int, u_char *, u_int); +const EVP_CIPHER *evp_aes_128_ctr(void); +void ssh_aes_ctr_iv(EVP_CIPHER_CTX *, int, u_char *, size_t); #endif /* Avoid some #ifdef. Code that uses these is unreachable without GCM */ From djm at mindrot.org Tue Jan 15 08:21:20 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Jan 2013 08:21:20 +1100 (EST) Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: On Mon, 14 Jan 2013, Katsumoto san wrote: > Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? The output of AuthorizedKeysCommand may contain any directive that is allowed in authorized_keys, so it's actually quite powerful. > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... You'll have to explain this example more, because it seems to me that this is well within the capabilities of the current AuthorizedKeysCommand. -d From apb at cequrux.com Tue Jan 15 09:24:19 2013 From: apb at cequrux.com (Alan Barrett) Date: Tue, 15 Jan 2013 00:24:19 +0200 Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: <20130114222419.GH6517@apb-laptoy.apb.alt.za> On Tue, 15 Jan 2013, Damien Miller wrote: > You'll have to explain this example more, because it seems to > me that this is well within the capabilities of the current > AuthorizedKeysCommand. Imagine that the result from "select authorized_keys_line from database where username = {x}" was so large that you did not want to process that much data. Then the ability to say "select authorized_keys_line from database where (username = {x} AND key = {y})" would be helpful. To be able to take advantage of that, the AuthorizedKeysCommand would have to be passed the key as a parameter. --apb (Alan Barrett) From imorgan at nas.nasa.gov Tue Jan 15 09:53:24 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 14 Jan 2013 14:53:24 -0800 Subject: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130114185547.GA3584@linux124.nas.nasa.gov> Message-ID: <20130114225324.GC3568@linux124.nas.nasa.gov> On Mon, Jan 14, 2013 at 15:15:43 -0600, Damien Miller wrote: > On Mon, 14 Jan 2013, Iain Morgan wrote: > > > Hi, > > > > The 20130110 snapshot fails to build against OpenSSL 0.9.8 and 1.0.0 > > with the following error: > ... > > Try this: > Thanks. The snapshot builds with the supplied patch, but there is stall a warning in cipher-ctr.c: cipher-ctr.c: In function ?evp_aes_128_ctr?: cipher-ctr.c:138: warning: assignment from incompatible pointer type For completeness, the following warnings show up during the build. cipher-acss.c:79: warning: assignment from incompatible pointer type cipher-bf1.c:100: warning: assignment from incompatible pointer type cipher-bf1.c:105: warning: assignment from incompatible pointer type cipher-ctr.c:138: warning: assignment from incompatible pointer type cipher-3des1.c:178: warning: assignment from incompatible pointer type I ran the regression tests, but they fail when building against older OpenSSL versions due to the lack of GCM support. -- Iain Morgan From mike at pair.com Thu Jan 17 02:40:59 2013 From: mike at pair.com (Mike Kelly) Date: Wed, 16 Jan 2013 10:40:59 -0500 Subject: HostKey Management Message-ID: <50F6CA0B.6020701@pair.com> Hi, As far as I can tell, when working in an environment with many servers, there seem to be several ways for your client to authenticate the HostKeys of each: 1) Set StrictHostKeyChecking=no, and hope you don't get MITM'd the first time you connect to a server. 2) Use SSHFP records (which generally requires you to have DNSSEC fully deployed to be meaningful compared to #1, I think?) 3) Build a massive /etc/ssh/ssh_known_hosts file with $N * $M entries, for $N servers using $M hostkey algorithms. 4) Use ssh-keygen to create a single "host certificate" key, and have a secure process to use to sign the host keys on all of your servers. Then, put that certificate in /etc/ssh/ssh_known_hosts on all your servers. 5) Use the same HostKeys everywhere, and just put those keys in /etc/ssh/ssh_known_hosts using a wildcard for your whole domain (e.g. "*.example.com ssh-rsa AAAAA....."). This makes revocation very difficult (since you need to securely re-key all of your servers). I also saw some discussion recently on this list about storing hostkeys in specialized security hardware. I'm not familiar with how "that stuff" works, but I assume it doesn't scale very well when you get up to thousands of servers, without a significant increase in your cost? ---- So, my questions are: 1) Is there some other option that I'm missing above? 2) Are there any good resources on "best practices" for any of the above? 3) Are there any tools that help make maintaining one of the above not-super-tedious? 4) Many of the above options seem to make revocation somewhat difficult (especially #5), but I think that in most other cases, "@revoked * ssh-rsa AAAAA...." should work to revoke a stolen key for a specific host? 5) How do "cloud" people handle host keys? As far as I understand, they often spawn and destroy many instances of servers over time, but I assume they still want to be sure they're reaching the right host somehow? For any answers to the above, a solution which requires minimal/no human interaction would be basically required. It's assumed that, say, public keys would be set up via some "other channel" to allow whatever access is required. Any advice would be appreciated. -- Mike Kelly From shogun147 at gmail.com Thu Jan 17 04:10:30 2013 From: shogun147 at gmail.com (Shogun) Date: Wed, 16 Jan 2013 19:10:30 +0200 Subject: AuthorizedKeysCommand In-Reply-To: <50F430D4.9060407@fifthhorseman.net> References: <50F430D4.9060407@fifthhorseman.net> Message-ID: <50F6DF06.2060303@gmail.com> 14.01.13 18:22, Daniel Kahn Gillmor ?????: > On 01/14/2013 10:36 AM, Katsumoto san wrote: >> We could set AuthorizedKeysCommand script, this will allow only to replace >> authorized_keys file with keys stored in a database... But why this command >> is so limited? >> >> Why i can't just set a command script which will get a username and public >> key as arguments and let him do it's own authorization?? > It sounds to me like you're proposing a different interface than the > current AuthorizedKeysCommand -- the current interface maps quite > cleanly to the AuthorizedKeysFile, and can be processed in a similar way > by ssh (it's just reading the list of authorized keys from a different > kind of file descriptor). Yes, like i've said AuthorizedKeysCommand now is almost like a simulation of AuthorizedKeysFile. > What you're proposing sounds rather different (but i agree it could be > useful). It's more of a KeyAuthorizationCommand (since it takes a > single key and decides whether it is authorized) than an > AuthorizedKeysCommand. Yes is not what now AuthorizedKeysCommand does, this could be named different (not so important), i've just expected from this command to work so. > > But note that an ssh client can offer several keys to the ssh server [0] > to see which ones might be acceptable. So the command you describe > might need to be invoked several times per attempted connection. > > Maybe you could propose a concrete specification for what you want? How > would the public key and user account be structured as arguments to the > command? > I'm not sure if client send all this keys at once or not, but if so will be good i think to run script one time and get all the keys as "array", also the script should get the username. Now command script could access $SSH_ORIGINAL_COMMAND from env so this data may also set there, or maybe pass as script arguments ... >> I think this will allow for much more powerful tricks. For example do to an >> database lookup with keys to identify and authorize or deny access and so >> on... > Note that the current API can still do a database lookup by the user > account, as long as the database is able to enumerate the keys that are > acceptable for authorizing access. This is also limited to the username. What if we have only a user for ex 'git' accessed by many users? So we need to identify them by pub keys like Github does. This also will allow more flexibility on controlling this action, custom acl's and so on... > --dkg > > [0] https://tools.ietf.org/html/rfc4252#section-7 > From shogun147 at gmail.com Thu Jan 17 04:11:25 2013 From: shogun147 at gmail.com (Shogun) Date: Wed, 16 Jan 2013 19:11:25 +0200 Subject: AuthorizedKeysCommand In-Reply-To: References: Message-ID: <50F6DF3D.2050507@gmail.com> Yes, i agree, this is also important. 14.01.13 19:00, Bostjan Skufca ?????: > Seems very useful. > > Implementation-wise I would not exclude AuthorizedKeysFile if > AuthorizedKeysCommand was present, because if script will be > connecting to external services which mail fail or hang, one still > needs access to machine in case of emergency. > In this respect, execution of external command should be time-limited > to avoid locking admin out of the system in troubled times. > > b. > > > On 14 January 2013 16:36, Katsumoto san > wrote: > > Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to > replace > authorized_keys file with keys stored in a database... But why > this command > is so limited? > > Why i can't just set a command script which will get a username > and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example > do to an > database lookup with keys to identify and authorize or deny access > and so > on... > > So is this so difficult to do? What do you all think about this? > > Thanks. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From shogun147 at gmail.com Thu Jan 17 04:12:01 2013 From: shogun147 at gmail.com (Shogun) Date: Wed, 16 Jan 2013 19:12:01 +0200 Subject: AuthorizedKeysCommand In-Reply-To: <20130114192236.GB3584@linux124.nas.nasa.gov> References: <20130114192236.GB3584@linux124.nas.nasa.gov> Message-ID: <50F6DF61.3040208@gmail.com> 14.01.13 21:22, Iain Morgan ?????: > On Mon, Jan 14, 2013 at 09:36:26 -0600, Katsumoto san wrote: >> Hi there, >> >> We could set AuthorizedKeysCommand script, this will allow only to replace >> authorized_keys file with keys stored in a database... But why this command >> is so limited? >> >> Why i can't just set a command script which will get a username and public >> key as arguments and let him do it's own authorization?? >> I think this will allow for much more powerful tricks. For example do to an >> database lookup with keys to identify and authorize or deny access and so >> on... >> >> So is this so difficult to do? What do you all think about this? >> > I believe the intent was to minimize the risks by keeping the > implementation simple. However, you can embed some flexibility either > in the command which you invoke or, potentiall, in the repository used > to store the keys. > > I don't quite see the advantage of the approach that you are suggesting. > Could you elaborate on it a bit? What sort of "tricks" are you thinking > of? More flexible doesn't mean more difficult or risky. The advantages is like you've said flexibility, a lot of flexibility. The users may write custom acl's and so on... why to limit them? For ex. Github uses his own patched ssh which allow to lookup a database for pub keys, this allow to users access repos with git at github.com:username/repository, so git "namespace" for many users... and many more advantages allowed by this approach. From peter at stuge.se Thu Jan 17 04:29:56 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 16 Jan 2013 18:29:56 +0100 Subject: AuthorizedKeysCommand In-Reply-To: <50F6DF06.2060303@gmail.com> References: <50F430D4.9060407@fifthhorseman.net> <50F6DF06.2060303@gmail.com> Message-ID: <20130116172956.10656.qmail@stuge.se> Shogun wrote: > I'm not sure if client send all this keys at once or not It does not. > Now command script could access $SSH_ORIGINAL_COMMAND from env so > this data may also set there, or maybe pass as script arguments ... Please look into the SSH protocol. It is not known at authentication time what the remote user wants to do once they have been authenticated. //Peter From dkg at fifthhorseman.net Thu Jan 17 12:06:23 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Jan 2013 20:06:23 -0500 Subject: HostKey Management In-Reply-To: <50F6CA0B.6020701@pair.com> References: <50F6CA0B.6020701@pair.com> Message-ID: <50F74E8F.1050808@fifthhorseman.net> On 01/16/2013 10:40 AM, Mike Kelly wrote: > 1) Is there some other option that I'm missing above? The monkeysphere is another option: http://web.monkeysphere.info/ The monkeysphere wraps your host key in an OpenPGP certificate, which allows you (and anyone) to certify the key's association with a given host; it also allows anyone to verify those certifications directly. For servers that the general public interacts with (e.g. pair's shared servers) this is could useful even beyond the in-house utility of known key distribution. The only human interactions needed would be to supply some credential to grant access to the certifying key when a machine is newly created (if you have an automated installation mechanism, this could be included directly). The monkeysphere also allows you to take care of revocations using standard OpenPGP revocation mechanisms, and to distribute those revocations via the same OpenPGP keyserver network that is already in use. If you don't want the keys public, you can also distribute them via a private keyserver (or a private keyserver network), which is pretty straightforward to install. hth, --dkg PS if it's not clear, i'm a contributor to the monkeysphere project. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Thu Jan 17 14:14:48 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Jan 2013 14:14:48 +1100 (EST) Subject: AuthorizedKeysCommand In-Reply-To: <20130114222419.GH6517@apb-laptoy.apb.alt.za> References: <20130114222419.GH6517@apb-laptoy.apb.alt.za> Message-ID: On Tue, 15 Jan 2013, Alan Barrett wrote: > On Tue, 15 Jan 2013, Damien Miller wrote: > > You'll have to explain this example more, because it seems to me that this > > is well within the capabilities of the current AuthorizedKeysCommand. > > Imagine that the result from "select authorized_keys_line from > database where username = {x}" was so large that you did not > want to process that much data. Then the ability to say "select > authorized_keys_line from database where (username = {x} AND key = > {y})" would be helpful. To be able to take advantage of that, the > AuthorizedKeysCommand would have to be passed the key as a parameter. Thanks, that's a good example. Would passing the entire public key on the commandline be preferable to just passing the fingerprint? -d From djm at mindrot.org Thu Jan 17 14:26:39 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Jan 2013 14:26:39 +1100 (EST) Subject: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: <20130114225324.GC3568@linux124.nas.nasa.gov> References: <20130114185547.GA3584@linux124.nas.nasa.gov> <20130114225324.GC3568@linux124.nas.nasa.gov> Message-ID: On Mon, 14 Jan 2013, Iain Morgan wrote: > Thanks. The snapshot builds with the supplied patch, but there is stall > a warning in cipher-ctr.c: > > cipher-ctr.c: In function ?evp_aes_128_ctr?: > cipher-ctr.c:138: warning: assignment from incompatible pointer type That's weird - we try to get that type right based on the installed OpenSSL version. Could you tell me the declaration of the function pointer do_cipher in OpenSSL's evp.h on your system and the the OPENSSL_VERSION_NUMBER from opensslv.h? > For completeness, the following warnings show up during the build. [different manifestations of the same problem] > I ran the regression tests, but they fail when building against older > OpenSSL versions due to the lack of GCM support. Please try this diff: Index: regress/cipher-speed.sh =================================================================== RCS file: /var/cvs/openssh/regress/cipher-speed.sh,v retrieving revision 1.8 diff -u -p -r1.8 cipher-speed.sh --- regress/cipher-speed.sh 12 Jan 2013 11:46:28 -0000 1.8 +++ regress/cipher-speed.sh 17 Jan 2013 03:18:54 -0000 @@ -16,11 +16,11 @@ ciphers="aes128-cbc 3des-cbc blowfish-cb arcfour128 arcfour256 arcfour aes192-cbc aes256-cbc rijndael-cbc at lysator.liu.se aes128-ctr aes192-ctr aes256-ctr" -config_defined OPENSSL_HAVE_EVPGCM && +config_defined OPENSSL_HAVE_EVPGCM && \ ciphers="$ciphers aes128-gcm at openssh.com aes256-gcm at openssh.com" macs="hmac-sha1 hmac-md5 umac-64 at openssh.com umac-128 at openssh.com hmac-sha1-96 hmac-md5-96" -config_defined HAVE_EVP_SHA256 && +config_defined HAVE_EVP_SHA256 && \ macs="$macs hmac-sha2-256 hmac-sha2-512" for c in $ciphers; do n=0; for m in $macs; do Index: regress/integrity.sh =================================================================== RCS file: /var/cvs/openssh/regress/integrity.sh,v retrieving revision 1.5 diff -u -p -r1.5 integrity.sh --- regress/integrity.sh 12 Jan 2013 12:10:50 -0000 1.5 +++ regress/integrity.sh 17 Jan 2013 03:19:02 -0000 @@ -16,7 +16,7 @@ macs="hmac-sha1 hmac-md5 umac-64 at openssh hmac-sha2-256-etm at openssh.com hmac-sha2-512-etm at openssh.com" # The following are not MACs, but ciphers with integrated integrity. They are # handled specially below. -config_defined OPENSSL_HAVE_EVPGCM && +config_defined OPENSSL_HAVE_EVPGCM && \ macs="$macs aes128-gcm at openssh.com aes256-gcm at openssh.com" # sshd-command for proxy (see test-exec.sh) Index: regress/try-ciphers.sh =================================================================== RCS file: /var/cvs/openssh/regress/try-ciphers.sh,v retrieving revision 1.15 diff -u -p -r1.15 try-ciphers.sh --- regress/try-ciphers.sh 12 Jan 2013 11:46:28 -0000 1.15 +++ regress/try-ciphers.sh 17 Jan 2013 03:19:33 -0000 @@ -6,8 +6,9 @@ tid="try ciphers" ciphers="aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour128 arcfour256 arcfour aes192-cbc aes256-cbc rijndael-cbc at lysator.liu.se - aes128-ctr aes192-ctr aes256-ctr - aes128-gcm at openssh.com aes256-gcm at openssh.com" + aes128-ctr aes192-ctr aes256-ctr" +config_defined OPENSSL_HAVE_EVPGCM && \ + ciphers="$ciphers aes128-gcm at openssh.com aes256-gcm at openssh.com" macs="hmac-sha1 hmac-md5 umac-64 at openssh.com umac-128 at openssh.com hmac-sha1-96 hmac-md5-96 hmac-sha1-etm at openssh.com hmac-md5-etm at openssh.com From mike at pair.com Fri Jan 18 03:08:29 2013 From: mike at pair.com (Mike Kelly) Date: Thu, 17 Jan 2013 11:08:29 -0500 Subject: HostKey Management In-Reply-To: <50F6CA0B.6020701@pair.com> References: <50F6CA0B.6020701@pair.com> Message-ID: <50F821FD.4010408@pair.com> On 01/16/2013 10:40 AM, Mike Kelly wrote: > As far as I can tell, when working in an environment with many servers, > there seem to be several ways for your client to authenticate the > HostKeys of each: > > [...] Two people replied to me off-list to mention GSSAPIKeyExchange, which seems to be part of some patches that aren't in the main OpenSSH distribution (yet?), with this being their source, as far as Google can tell me: http://www.sxw.org.uk/computing/patches/openssh.html Those don't seem to have been updated for versions 5.8, 5.9, 6.0, or 6.1, though... so I guess it's been abandoned? Also, as far as I'm aware (though, maybe I've just not learned enough about Kerberos), using Kerberos basically requires someone to interactively (and somewhat regularly) kinit, to get fresh credentials. For a situation where you want to allow various servers to talk to each other over an SSH channel, without any direct human intervention (e.g. cron jobs, etc)... it seems that would rule out Kerberos completely? But, maybe there's "something" that I'm missing, that would allow Kerberos to be used like Public Keys can be now? -- Mike Kelly From dkg at fifthhorseman.net Fri Jan 18 04:03:24 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Jan 2013 12:03:24 -0500 Subject: HostKey Management In-Reply-To: <50F821FD.4010408@pair.com> References: <50F6CA0B.6020701@pair.com> <50F821FD.4010408@pair.com> Message-ID: <50F82EDC.8070409@fifthhorseman.net> On 01/17/2013 11:08 AM, Mike Kelly wrote: > Two people replied to me off-list to mention GSSAPIKeyExchange, which > seems to be part of some patches that aren't in the main OpenSSH > distribution (yet?), with this being their source, as far as Google can > tell me: > > http://www.sxw.org.uk/computing/patches/openssh.html > > Those don't seem to have been updated for versions 5.8, 5.9, 6.0, or > 6.1, though... so I guess it's been abandoned? GSSAPIKeyExchange is included in the debian packaging of OpenSSH (has been for several years now) and i can verify that it works with 6.0 (i haven't tried 6.1 yet, which is in debian's experimental repository). If the "official" GSSAPIKeyExchange patches aren't explicitly updated for your preferred version, you might want to look at the patches as applied in debian's openssh packages (even if you don't use debian). > Also, as far as I'm aware (though, maybe I've just not learned enough > about Kerberos), using Kerberos basically requires someone to > interactively (and somewhat regularly) kinit, to get fresh credentials. > For a situation where you want to allow various servers to talk to each > other over an SSH channel, without any direct human intervention (e.g. > cron jobs, etc)... it seems that would rule out Kerberos completely? > But, maybe there's "something" that I'm missing, that would allow > Kerberos to be used like Public Keys can be now? i think the thing you're interested in is kerberos keytabs. You'd use the keytab file to initialize your kerberos credentials cache, and then rely on that credentials cache to bootstrap the GSSAPIKeyExchange. This can all be done in an automated fashion (as long as your KDC is online and available) hth, --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 carson at taltos.org Fri Jan 18 04:12:19 2013 From: carson at taltos.org (Carson Gaspar) Date: Thu, 17 Jan 2013 09:12:19 -0800 Subject: HostKey Management In-Reply-To: <50F821FD.4010408@pair.com> References: <50F6CA0B.6020701@pair.com> <50F821FD.4010408@pair.com> Message-ID: <50F830F3.7030906@taltos.org> On 1/17/13 8:08 AM, Mike Kelly wrote: > Two people replied to me off-list to mention GSSAPIKeyExchange, which > seems to be part of some patches that aren't in the main OpenSSH > distribution (yet?), with this being their source, as far as Google can > tell me: > > http://www.sxw.org.uk/computing/patches/openssh.html > > Those don't seem to have been updated for versions 5.8, 5.9, 6.0, or > 6.1, though... so I guess it's been abandoned? I hope not. I really hope it makes it into mainline openssh - we rely on it heavily, and many vendors ship with that patch (Red Hat does, and Oracle has it in their fork). > Also, as far as I'm aware (though, maybe I've just not learned enough > about Kerberos), using Kerberos basically requires someone to > interactively (and somewhat regularly) kinit, to get fresh credentials. > For a situation where you want to allow various servers to talk to each > other over an SSH channel, without any direct human intervention (e.g. > cron jobs, etc)... it seems that would rule out Kerberos completely? > But, maybe there's "something" that I'm missing, that would allow > Kerberos to be used like Public Keys can be now? There are many good docs on KRB5 - I won't try and teach you about it here ;-) Yes, there is a way - local keytabs (analogous to id_dsa), plus something like kstart / krenew to keep the credential cache fresh. -- Carson From imorgan at nas.nasa.gov Fri Jan 18 09:56:05 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 17 Jan 2013 14:56:05 -0800 Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() Message-ID: <20130117225605.GC19962@linux124.nas.nasa.gov> Oops, I meant to CC the list on this. -- Iain ----- Forwarded message from Iain Morgan ----- Date: Thu, 17 Jan 2013 14:51:01 -0800 From: Iain Morgan To: Damien Miller Subject: Re: Inconsisten declaration of ssh_aes_ctr_iv() On Wed, Jan 16, 2013 at 21:26:39 -0600, Damien Miller wrote: > On Mon, 14 Jan 2013, Iain Morgan wrote: > > > Thanks. The snapshot builds with the supplied patch, but there is stall > > a warning in cipher-ctr.c: > > > > cipher-ctr.c: In function ?evp_aes_128_ctr?: > > cipher-ctr.c:138: warning: assignment from incompatible pointer type > > That's weird - we try to get that type right based on the installed > OpenSSL version. > > Could you tell me the declaration of the function pointer do_cipher in > OpenSSL's evp.h on your system and the the OPENSSL_VERSION_NUMBER from > opensslv.h? % grep -A1 do_cipher /usr/include/openssl/evp.h int (*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, size_t inl);/* encrypt/decrypt data */ % grep OPENSSL_VERSION_NUMBER /usr/include/openssl/opensslv.h #define OPENSSL_VERSION_NUMBER 0x10000003L > > > For completeness, the following warnings show up during the build. > > [different manifestations of the same problem] > > > I ran the regression tests, but they fail when building against older > > OpenSSL versions due to the lack of GCM support. > > Please try this diff: > I applied the diff you supplied, along with the previous diff. The regression tests got further along, but now fail in integrity.sh: run test integrity.sh ... test integrity: hmac-sha1 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2300 test integrity: hmac-sha1 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2301 test integrity: hmac-sha1 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2302 test integrity: hmac-sha1 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2303 test integrity: hmac-sha1 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2304 test integrity: hmac-sha1 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2305 test integrity: hmac-sha1 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2306 test integrity: hmac-sha1 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2307 test integrity: hmac-sha1 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2308 test integrity: hmac-sha1 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha1: no mac errors hmac-sha1: expected 10 mac errors, got 0 test integrity: hmac-md5 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2300 test integrity: hmac-md5 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2301 test integrity: hmac-md5 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2302 test integrity: hmac-md5 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2303 test integrity: hmac-md5 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2304 test integrity: hmac-md5 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2305 test integrity: hmac-md5 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2306 test integrity: hmac-md5 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2307 test integrity: hmac-md5 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2308 test integrity: hmac-md5 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-md5: no mac errors hmac-md5: expected 10 mac errors, got 0 test integrity: umac-64 at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2300 test integrity: umac-64 at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2301 test integrity: umac-64 at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2302 test integrity: umac-64 at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2303 test integrity: umac-64 at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2304 test integrity: umac-64 at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2305 test integrity: umac-64 at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2306 test integrity: umac-64 at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2307 test integrity: umac-64 at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2308 test integrity: umac-64 at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64 at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 umac-64 at openssh.com: no mac errors umac-64 at openssh.com: expected 10 mac errors, got 0 test integrity: umac-128 at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2300 test integrity: umac-128 at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2301 test integrity: umac-128 at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2302 test integrity: umac-128 at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2303 test integrity: umac-128 at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2304 test integrity: umac-128 at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2305 test integrity: umac-128 at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2306 test integrity: umac-128 at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2307 test integrity: umac-128 at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2308 test integrity: umac-128 at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128 at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 umac-128 at openssh.com: no mac errors umac-128 at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-sha1-96 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2300 test integrity: hmac-sha1-96 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2301 test integrity: hmac-sha1-96 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2302 test integrity: hmac-sha1-96 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2303 test integrity: hmac-sha1-96 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2304 test integrity: hmac-sha1-96 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2305 test integrity: hmac-sha1-96 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2306 test integrity: hmac-sha1-96 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2307 test integrity: hmac-sha1-96 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2308 test integrity: hmac-sha1-96 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha1-96: no mac errors hmac-sha1-96: expected 10 mac errors, got 0 test integrity: hmac-md5-96 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2300 test integrity: hmac-md5-96 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2301 test integrity: hmac-md5-96 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2302 test integrity: hmac-md5-96 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2303 test integrity: hmac-md5-96 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2304 test integrity: hmac-md5-96 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2305 test integrity: hmac-md5-96 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2306 test integrity: hmac-md5-96 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2307 test integrity: hmac-md5-96 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2308 test integrity: hmac-md5-96 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-md5-96: no mac errors hmac-md5-96: expected 10 mac errors, got 0 test integrity: hmac-sha2-256 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2300 test integrity: hmac-sha2-256 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2301 test integrity: hmac-sha2-256 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2302 test integrity: hmac-sha2-256 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2303 test integrity: hmac-sha2-256 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2304 test integrity: hmac-sha2-256 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2305 test integrity: hmac-sha2-256 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2306 test integrity: hmac-sha2-256 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2307 test integrity: hmac-sha2-256 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2308 test integrity: hmac-sha2-256 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha2-256: no mac errors hmac-sha2-256: expected 10 mac errors, got 0 test integrity: hmac-sha2-512 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2300 test integrity: hmac-sha2-512 @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2301 test integrity: hmac-sha2-512 @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2302 test integrity: hmac-sha2-512 @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2303 test integrity: hmac-sha2-512 @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2304 test integrity: hmac-sha2-512 @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2305 test integrity: hmac-sha2-512 @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2306 test integrity: hmac-sha2-512 @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2307 test integrity: hmac-sha2-512 @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2308 test integrity: hmac-sha2-512 @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512 at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha2-512: no mac errors hmac-sha2-512: expected 10 mac errors, got 0 test integrity: hmac-sha1-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2300 test integrity: hmac-sha1-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2301 test integrity: hmac-sha1-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2302 test integrity: hmac-sha1-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2303 test integrity: hmac-sha1-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2304 test integrity: hmac-sha1-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2305 test integrity: hmac-sha1-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2306 test integrity: hmac-sha1-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2307 test integrity: hmac-sha1-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2308 test integrity: hmac-sha1-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha1-etm at openssh.com: no mac errors hmac-sha1-etm at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-md5-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2300 test integrity: hmac-md5-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2301 test integrity: hmac-md5-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2302 test integrity: hmac-md5-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2303 test integrity: hmac-md5-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2304 test integrity: hmac-md5-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2305 test integrity: hmac-md5-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2306 test integrity: hmac-md5-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2307 test integrity: hmac-md5-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2308 test integrity: hmac-md5-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-md5-etm at openssh.com: no mac errors hmac-md5-etm at openssh.com: expected 10 mac errors, got 0 test integrity: umac-64-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2300 test integrity: umac-64-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2301 test integrity: umac-64-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2302 test integrity: umac-64-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2303 test integrity: umac-64-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2304 test integrity: umac-64-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2305 test integrity: umac-64-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2306 test integrity: umac-64-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2307 test integrity: umac-64-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2308 test integrity: umac-64-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-64-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 umac-64-etm at openssh.com: no mac errors umac-64-etm at openssh.com: expected 10 mac errors, got 0 test integrity: umac-128-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2300 test integrity: umac-128-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2301 test integrity: umac-128-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2302 test integrity: umac-128-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2303 test integrity: umac-128-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2304 test integrity: umac-128-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2305 test integrity: umac-128-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2306 test integrity: umac-128-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2307 test integrity: umac-128-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2308 test integrity: umac-128-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac umac-128-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 umac-128-etm at openssh.com: no mac errors umac-128-etm at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-sha1-96-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2300 test integrity: hmac-sha1-96-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2301 test integrity: hmac-sha1-96-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2302 test integrity: hmac-sha1-96-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2303 test integrity: hmac-sha1-96-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2304 test integrity: hmac-sha1-96-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2305 test integrity: hmac-sha1-96-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2306 test integrity: hmac-sha1-96-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2307 test integrity: hmac-sha1-96-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2308 test integrity: hmac-sha1-96-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha1-96-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha1-96-etm at openssh.com: no mac errors hmac-sha1-96-etm at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-md5-96-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2300 test integrity: hmac-md5-96-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2301 test integrity: hmac-md5-96-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2302 test integrity: hmac-md5-96-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2303 test integrity: hmac-md5-96-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2304 test integrity: hmac-md5-96-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2305 test integrity: hmac-md5-96-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2306 test integrity: hmac-md5-96-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2307 test integrity: hmac-md5-96-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2308 test integrity: hmac-md5-96-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-md5-96-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-md5-96-etm at openssh.com: no mac errors hmac-md5-96-etm at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-sha2-256-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2300 test integrity: hmac-sha2-256-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2301 test integrity: hmac-sha2-256-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2302 test integrity: hmac-sha2-256-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2303 test integrity: hmac-sha2-256-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2304 test integrity: hmac-sha2-256-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2305 test integrity: hmac-sha2-256-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2306 test integrity: hmac-sha2-256-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2307 test integrity: hmac-sha2-256-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2308 test integrity: hmac-sha2-256-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-256-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha2-256-etm at openssh.com: no mac errors hmac-sha2-256-etm at openssh.com: expected 10 mac errors, got 0 test integrity: hmac-sha2-512-etm at openssh.com @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2300 test integrity: hmac-sha2-512-etm at openssh.com @2301 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2301 test integrity: hmac-sha2-512-etm at openssh.com @2302 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2302 test integrity: hmac-sha2-512-etm at openssh.com @2303 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2303 test integrity: hmac-sha2-512-etm at openssh.com @2304 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2304 test integrity: hmac-sha2-512-etm at openssh.com @2305 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2305 test integrity: hmac-sha2-512-etm at openssh.com @2306 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2306 test integrity: hmac-sha2-512-etm at openssh.com @2307 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2307 test integrity: hmac-sha2-512-etm at openssh.com @2308 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2308 test integrity: hmac-sha2-512-etm at openssh.com @2309 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. unexpected error mac hmac-sha2-512-etm at openssh.com at 2309 test integrity: 10 errors: mac 0 padding 0 length 0 hmac-sha2-512-etm at openssh.com: no mac errors hmac-sha2-512-etm at openssh.com: expected 10 mac errors, got 0 failed integrity -- Iain Morgan ----- End forwarded message ----- -- Iain Morgan From mike at pair.com Fri Jan 18 09:57:51 2013 From: mike at pair.com (Mike Kelly) Date: Thu, 17 Jan 2013 17:57:51 -0500 Subject: HostKey Management In-Reply-To: <50F830F3.7030906@taltos.org> References: <50F6CA0B.6020701@pair.com> <50F821FD.4010408@pair.com> <50F830F3.7030906@taltos.org> Message-ID: <50F881EF.5000408@pair.com> On 01/17/2013 12:12 PM, Carson Gaspar wrote: > On 1/17/13 8:08 AM, Mike Kelly wrote: >> Two people replied to me off-list to mention GSSAPIKeyExchange, which >> seems to be part of some patches that aren't in the main OpenSSH >> distribution (yet?), with this being their source, as far as Google can >> tell me: >> >> http://www.sxw.org.uk/computing/patches/openssh.html >> >> Those don't seem to have been updated for versions 5.8, 5.9, 6.0, or >> 6.1, though... so I guess it's been abandoned? > > I hope not. I really hope it makes it into mainline openssh - we rely on > it heavily, and many vendors ship with that patch (Red Hat does, and > Oracle has it in their fork). > >> Also, as far as I'm aware (though, maybe I've just not learned enough >> about Kerberos), using Kerberos basically requires someone to >> interactively (and somewhat regularly) kinit, to get fresh credentials. >> For a situation where you want to allow various servers to talk to each >> other over an SSH channel, without any direct human intervention (e.g. >> cron jobs, etc)... it seems that would rule out Kerberos completely? >> But, maybe there's "something" that I'm missing, that would allow >> Kerberos to be used like Public Keys can be now? > > There are many good docs on KRB5 - I won't try and teach you about it > here ;-) > > Yes, there is a way - local keytabs (analogous to id_dsa), plus > something like kstart / krenew to keep the credential cache fresh. Thanks to everyone who mentioned "keytabs", I'll try to find out more about them (I have the O'Reilly Kerberos book, and I've been slowly working my way through it). But, as someone mentioned (maybe just off-list), this still has some shortcomings compared to public keys. The biggest is that, as I have gathered so far, you can't tie a forced command to the credentials. I guess that the closest workaround would be to have a specific user that is used to log in for these specific tasks, which could have a ForceCommand in a Match User block in sshd_config (maybe in combination with, say, sudo so that things that maybe need to be run as some other user instead can be?). -- Mike Kelly From matthew.nygard.dodd at gmail.com Fri Jan 18 11:04:26 2013 From: matthew.nygard.dodd at gmail.com (Matthew N. Dodd) Date: Thu, 17 Jan 2013 19:04:26 -0500 Subject: HostKey Management In-Reply-To: <50F881EF.5000408@pair.com> References: <50F6CA0B.6020701@pair.com> <50F821FD.4010408@pair.com> <50F830F3.7030906@taltos.org> <50F881EF.5000408@pair.com> Message-ID: <50F8918A.3070208@gmail.com> On 1/17/13 5:57 PM, Mike Kelly wrote: > But, as someone mentioned (maybe just off-list), this still has some > shortcomings compared to public keys. The biggest is that, as I have > gathered so far, you can't tie a forced command to the credentials. I > guess that the closest workaround would be to have a specific user that > is used to log in for these specific tasks, which could have a > ForceCommand in a Match User block in sshd_config (maybe in combination > with, say, sudo so that things that maybe need to be run as some other > user instead can be?). https://bugzilla.mindrot.org/show_bug.cgi?id=1927 Bug 1927 - authorized_credentials (aka authorized_keys for GSSAPI-MIC) I'll spend some time updating it if there is any interest. From Iain.Morgan at nasa.gov Fri Jan 18 11:18:18 2013 From: Iain.Morgan at nasa.gov (Iain Morgan) Date: Thu, 17 Jan 2013 16:18:18 -0800 Subject: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130114185547.GA3584@linux124.nas.nasa.gov> <20130114225324.GC3568@linux124.nas.nasa.gov> <20130117225101.GB19962@linux124.nas.nasa.gov> Message-ID: <20130118001818.GD19962@linux124.nas.nasa.gov> On Thu, Jan 17, 2013 at 17:19:35 -0600, Damien Miller wrote: > On Thu, 17 Jan 2013, Iain Morgan wrote: > > > > Could you tell me the declaration of the function pointer do_cipher in > > > OpenSSL's evp.h on your system and the the OPENSSL_VERSION_NUMBER from > > > opensslv.h? > > > > % grep -A1 do_cipher /usr/include/openssl/evp.h > > int (*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out, > > const unsigned char *in, size_t inl);/* encrypt/decrypt data */ > > > > % grep OPENSSL_VERSION_NUMBER /usr/include/openssl/opensslv.h > > #define OPENSSL_VERSION_NUMBER 0x10000003L > > Is this a beta? This should help (on top of you existing diffs): No, this is the version included with RHEL 6.3. % /usr/bin/openssl version -a OpenSSL 1.0.0-fips 29 Mar 2010 built on: Wed Aug 15 12:48:02 EDT 2012 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: "/etc/pki/tls" engines: aesni dynamic That cleared up the warnings. -- Iain Morgan From djm at mindrot.org Fri Jan 18 11:19:15 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 18 Jan 2013 11:19:15 +1100 (EST) Subject: Inconsisten declaration of ssh_aes_ctr_iv() (fwd) Message-ID: ---------- Forwarded message ---------- Date: Fri, 18 Jan 2013 10:19:35 +1100 (EST) From: Damien Miller To: Iain Morgan Subject: Re: Inconsisten declaration of ssh_aes_ctr_iv() On Thu, 17 Jan 2013, Iain Morgan wrote: > > Could you tell me the declaration of the function pointer do_cipher in > > OpenSSL's evp.h on your system and the the OPENSSL_VERSION_NUMBER from > > opensslv.h? > > % grep -A1 do_cipher /usr/include/openssl/evp.h > int (*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out, > const unsigned char *in, size_t inl);/* encrypt/decrypt data */ > > % grep OPENSSL_VERSION_NUMBER /usr/include/openssl/opensslv.h > #define OPENSSL_VERSION_NUMBER 0x10000003L Is this a beta? This should help (on top of you existing diffs): Index: openbsd-compat/openssl-compat.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/openssl-compat.h,v retrieving revision 1.21 diff -u -p -r1.21 openssl-compat.h --- openbsd-compat/openssl-compat.h 9 Jan 2013 05:42:49 -0000 1.21 +++ openbsd-compat/openssl-compat.h 17 Jan 2013 23:13:34 -0000 @@ -40,7 +40,7 @@ # define EVP_CIPHER_CTX_get_app_data(e) ((e)->app_data) #endif -#if OPENSSL_VERSION_NUMBER < 0x1000000fL +#if OPENSSL_VERSION_NUMBER < 0x10000001L # define LIBCRYPTO_EVP_INL_TYPE unsigned int #else # define LIBCRYPTO_EVP_INL_TYPE size_t > I applied the diff you supplied, along with the previous diff. The > regression tests got further along, but now fail in integrity.sh: > > run test integrity.sh ... > test integrity: hmac-sha1 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. I expect this is the test that is choking rather than ssh/sshd, otherwise the regress tests wouldn't have made it that far without error (given the ones you see here). This test depends on the small modpipe program that is built from modpipe.c. You can test if it is working via: $ echo "hello there" | ./modpipe -m andor:5:0x00:0x2D hello-there If it isn't working properly then the test will fail in a way similar to when you are seeing. -d From ted_smith1 at verizon.net Fri Jan 18 11:38:59 2013 From: ted_smith1 at verizon.net (Ted Smith) Date: Thu, 17 Jan 2013 19:38:59 -0500 Subject: sftp does not allow rename across file system Message-ID: <50F899A3.4040405@verizon.net> Hello: I got the error EXDEV (Invalid cross-device link) when renaming one file to another directory that is actually mounting another file system. I am using SSH-2.0-OpenSSH_6 with standard SFTP setup as below Subsystem sftp internal-sftp Match group sftponly ChrootDirectory /home/sftp/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp there are two subdirs in a user home subPlain (a plain unix dir) subMounted (a dir that is actually mounting a different file system, or using mount --bind subMounted ) when using sftp rename rename subPlaib/F1 subPlaib/F2 works fine. but rename subPlaib/F1 subMounted/F2 failed strace output shows the error as read(0, "\0\0\0H\310\0\0\0&\0\0\0\30posix-rename at openss"..., 16384) = 76 rename("/johnson/ttt", "/johnson/shared/kkk") = -1 EXDEV (Invalid cross-device link) select(2, [0], [1], NULL, NULL) = 1 (out [1]) write(1, "\0\0\0\30e\0\0\0&\0\0\0\4\0\0\0\7Failure\0\0\0\0", 28) = 28 I have tried with different sftp clients without success. Any help would be appreciated. Thanks -Ted From djm at mindrot.org Fri Jan 18 11:48:48 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 18 Jan 2013 11:48:48 +1100 (EST) Subject: sftp does not allow rename across file system In-Reply-To: <50F899A3.4040405@verizon.net> References: <50F899A3.4040405@verizon.net> Message-ID: On Thu, 17 Jan 2013, Ted Smith wrote: > Hello: > I got the error > EXDEV (Invalid cross-device link) > when renaming one file to another directory that is actually mounting another > file system. This is expected behaviour at the moment. The sftp protocol doesn't have a mechanism to do cross-device rename (a misnomer, since it isn't renaming but copying). Fixing this will require a protocol extension. It isn't hard, but someone needs to do the work. -d From ted_smith1 at verizon.net Fri Jan 18 12:10:47 2013 From: ted_smith1 at verizon.net (Ted Smith) Date: Thu, 17 Jan 2013 20:10:47 -0500 Subject: sftp does not allow rename across file system In-Reply-To: References: <50F899A3.4040405@verizon.net> Message-ID: <50F8A117.8080101@verizon.net> Would it be possible for openssh to simulate the desired outcome by doing the copying/removal for renaming commnd, when detecting the cross device path? To client, it does not make difference so it would not seem to break the protocol and transparent. On 1/17/2013 7:48 PM, Damien Miller wrote: > On Thu, 17 Jan 2013, Ted Smith wrote: > >> Hello: >> I got the error >> EXDEV (Invalid cross-device link) >> when renaming one file to another directory that is actually mounting another >> file system. > This is expected behaviour at the moment. The sftp protocol doesn't have > a mechanism to do cross-device rename (a misnomer, since it isn't renaming > but copying). > > Fixing this will require a protocol extension. It isn't hard, but someone > needs to do the work. > > -d > From nicholas at nicholaswilson.me.uk Sun Jan 20 09:31:12 2013 From: nicholas at nicholaswilson.me.uk (Nicholas Wilson) Date: Sat, 19 Jan 2013 22:31:12 +0000 Subject: PAM function ordering In-Reply-To: References: Message-ID: Dear all, I've been looking into hacking with some PAM modules, and thought I could learn from the OpenSSH source (it's probably the closest thing to a canonical cross-platform consumer of the API). One thing I've noticed I don't understand though is how OpenSSH's invocation of do_pam_session/setcred can work (in main of the process forked in sshd.c). Ignoring privsep for the moment, if we're doing challenge-response then pam_authenticate is happening in the PAM "thread", so the pam_h we call pam_setcred with isn't the one that we called pam_authenticate with. The pam_h the main process is using at this stage seems to be the one created in sshpam_init_authctx (or mm_init_auth_ctx with privsep) and hasn't had pam_authenticate called on it, has it? I've checked FreeBSD's pam_krb5 source, for example, and I can see that it uses pam_set/get_data to stash the krb5ccache between calls to pam_authenticate and pam_setcred. I don't understand how OpenSSH carries that data over from the "thread" back to the main process; I can only see the environment list being copied across. I can also see that OpenSSH swallows all errors from pam_setcred if pam_authenticate wasn't called, so clearly this isn't going to stop connections. I remain confused though how the krb5 module in BSD could ever have its setcred function called successfully by OpenSSH. Perhaps it's an eccentric Kerberos implementation? Similarly, I wonder if there are any known guidelines on how pam_setcred(DESTROY) and pam_close_session are meant to be called, and if there are any constraints in the order between to be portable? Thanks ever so much for any clues you could give me. Hopefully I'm simply missing something. Nicholas ---------- Nicholas Wilson: nicholas at nicholaswilson.uk From djm at mindrot.org Sun Jan 20 13:02:09 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 20 Jan 2013 13:02:09 +1100 (EST) Subject: PAM function ordering In-Reply-To: References: Message-ID: On Sat, 19 Jan 2013, Nicholas Wilson wrote: > Dear all, > > I've been looking into hacking with some PAM modules, and thought I could > learn from the OpenSSH source (it's probably the closest thing to a > canonical cross-platform consumer of the API). Hmmm. We are probably not the best learning example for PAM, we're probably more of a cautionary example of how PAM's API doesn't fit with modern, privilege- minimising and separated applications. > One thing I've noticed I don't understand though is how OpenSSH's > invocation of do_pam_session/setcred can work (in main of the process > forked in sshd.c). Ignoring privsep for the moment, if we're doing > challenge-response then pam_authenticate is happening in the PAM "thread", > so the pam_h we call pam_setcred with isn't the one that we called > pam_authenticate with. The pam_h the main process is using at this stage > seems to be the one created in sshpam_init_authctx (or mm_init_auth_ctx > with privsep) and hasn't had pam_authenticate called on it, has it? > > I've checked FreeBSD's pam_krb5 source, for example, and I can see that it > uses pam_set/get_data to stash the krb5ccache between calls to > pam_authenticate and pam_setcred. I don't understand how OpenSSH carries > that data over from the "thread" back to the main process; I can only see > the environment list being copied across. Right, anything that uses pam_get/set_data will break on OpenSSH. So far we've accepted this as a price of keeping our PAM code sane and easy to reason about. Various alternatives have been suggested, but all have turned my sunglasses black. > I can also see that OpenSSH swallows all errors from pam_setcred if > pam_authenticate wasn't called, so clearly this isn't going to stop > connections. I remain confused though how the krb5 module in BSD could ever > have its setcred function called successfully by OpenSSH. Perhaps it's an > eccentric Kerberos implementation? I think most people use the GSSAPI support in OpenSSH directly instead of pam_krb5. > Similarly, I wonder if there are any known guidelines on how > pam_setcred(DESTROY) and pam_close_session are meant to be called, and if > there are any constraints in the order between to be portable? No, there are no guidelines for most of PAM. That's part of the problem. Darren has a list of problems with PAM at http://www.dtucker.net/pam/ -d From nicholas at nicholaswilson.me.uk Sun Jan 20 20:53:35 2013 From: nicholas at nicholaswilson.me.uk (Nicholas Wilson) Date: Sun, 20 Jan 2013 09:53:35 +0000 Subject: PAM function ordering In-Reply-To: References: Message-ID: Damien, On Jan 20, 2013 2:02 AM, "Damien Miller" wrote: > > Hmmm. We are probably not the best learning example for PAM, we're > probably more of a cautionary example of how PAM's API doesn't fit with > modern, privilege- minimising and separated applications. It's certainly true that in my application, we make a few more concessions to PAM in our architecture than OpenSSH does! It is possible to fork off a PAM process for authentication, then session/setcred, and keep it around to reuse for spawning commands. The main process can still use privsep to avoid interpreting client input in the privileged process. Regardless though of whether you're a model PAM consumer or not, you at least have been tested with every implementation and module by someone. > Right, anything that uses pam_get/set_data will break on OpenSSH. So > far we've accepted this as a price of keeping our PAM code sane and > easy to reason about. Various alternatives have been suggested, but all > have turned my sunglasses black. Would you use a "pam_getdatalist" function then if it were available, as a way of transferring module context from one process to another? You could suggest it to OpenPAM or something and pull it in with autoconf. > > Similarly, I wonder if there are any known guidelines on how > > pam_setcred(DESTROY) and pam_close_session are meant to be called, and if > > there are any constraints in the order between to be portable? > > No, there are no guidelines for most of PAM. That's part of the problem. > > Darren has a list of problems with PAM at http://www.dtucker.net/pam/ That's an extremely helpful list, thank you. I've gleaned most of that, plus some, from research already though. There are clear difficulties with the setcred(ESTABLISH)/open_session order, which is why I asked specifically whether there were known issues with setcred(DESTROY)/close_session. Thanks for the feedback, Damien. Nicholas From xi.wang at gmail.com Sun Jan 27 20:49:10 2013 From: xi.wang at gmail.com (Xi Wang) Date: Sun, 27 Jan 2013 04:49:10 -0500 Subject: null pointer dereference in krl.c? Message-ID: <5104F816.8040209@gmail.com> Hi, In ssh_krl_from_blob(), krl.c:984, /* Record keys used to sign the KRL */ xrealloc(ca_used, nca_used + 1, sizeof(*ca_used)); ca_used[nca_used++] = key; The result of `xrealloc' is never assigned to `ca_used', which remains a null pointer. Will ca_used[...] crash?. Did I miss anything? Thanks. - xi From djm at mindrot.org Sun Jan 27 20:56:01 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Jan 2013 20:56:01 +1100 (EST) Subject: null pointer dereference in krl.c? In-Reply-To: <5104F816.8040209@gmail.com> References: <5104F816.8040209@gmail.com> Message-ID: On Sun, 27 Jan 2013, Xi Wang wrote: > Hi, > > In ssh_krl_from_blob(), krl.c:984, > > /* Record keys used to sign the KRL */ > xrealloc(ca_used, nca_used + 1, sizeof(*ca_used)); > ca_used[nca_used++] = key; > > The result of `xrealloc' is never assigned to `ca_used', which remains > a null pointer. Will ca_used[...] crash?. Did I miss anything? Yes, I'll commit a fix. -d From djm at mindrot.org Sun Jan 27 21:18:15 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Jan 2013 21:18:15 +1100 (EST) Subject: null pointer dereference in krl.c? In-Reply-To: References: <5104F816.8040209@gmail.com> Message-ID: On Sun, 27 Jan 2013, Damien Miller wrote: > > The result of `xrealloc' is never assigned to `ca_used', which remains > > a null pointer. Will ca_used[...] crash?. Did I miss anything? > > Yes, I'll commit a fix. BTW this bug was in the KRL signature code that isn't really used yet, since ssh-keygen currently lacks the ability to sign KRLs. I hope to add this shortly. -d From dmitry.kurochkin at gmail.com Tue Jan 29 12:32:09 2013 From: dmitry.kurochkin at gmail.com (Dmitry Kurochkin) Date: Tue, 29 Jan 2013 05:32:09 +0400 Subject: [PATCH] Android port Message-ID: <87vcag7p0m.fsf@gmail.com> Hi all. I am experimenting with building OpenSSH server for Android. The attached patch makes OpenSSH successfully build (at least) using Android NDK with libldns. The patch is mostly trivial. The biggest change perhaps is disabling password authentication code. I would like to receive feedback and hopefully get it accepted into the mainline eventually. Regards, Dmitry -------------- next part -------------- A non-text attachment was scrubbed... Name: android-port-t1.patch Type: text/x-diff Size: 22584 bytes Desc: not available URL: From tahlholm at gmail.com Tue Jan 29 22:46:53 2013 From: tahlholm at gmail.com (Teemu Ahlholm) Date: Tue, 29 Jan 2013 13:46:53 +0200 Subject: Subscribing to list openssh-unix-dev@mindrot.org Message-ID: Hi, Please could you subscribe me to this list openssh-unix-dev at mindrot.org. BR, Teemu Ahlholm From dtucker at zip.com.au Tue Jan 29 23:43:48 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 29 Jan 2013 23:43:48 +1100 Subject: Subscribing to list openssh-unix-dev@mindrot.org In-Reply-To: References: Message-ID: <20130129124348.GA18672@gate.dtucker.net> On Tue, Jan 29, 2013 at 01:46:53PM +0200, Teemu Ahlholm wrote: > Hi, > > Please could you subscribe me to this list openssh-unix-dev at mindrot.org. it's self-service, see the URL in the footer of your post > BR, > Teemu Ahlholm > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- 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.