[opensuse] Unencrypted File Transfers: Howto?
Hi Folks, We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks. In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place. So, what are the options for sending many large files between machines without encryption? SSH insists on encryption, but there are apparently patches that will allow it to be turned off. Maybe wrap netcat up with some scripts? Maybe rsync could be persuaded to use netcat? Byte the bullet and learn munge? Any other options? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 2:16 PM, Lew Wolfgang wrote:
Hi Folks,
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Maybe wrap netcat up with some scripts?
Maybe rsync could be persuaded to use netcat?
Byte the bullet and learn munge?
Any other options?
ftp $ rpm -qf /usr/bin/ftp tnftp-20141104-5.1.x86_64 lftp-4.7.4-2.6.1.x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 12:18 PM, ken wrote:
On 8/29/19 2:16 PM, Lew Wolfgang wrote:
Hi Folks,
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Maybe wrap netcat up with some scripts?
Maybe rsync could be persuaded to use netcat?
Byte the bullet and learn munge?
Any other options? ftp
$ rpm -qf /usr/bin/ftp tnftp-20141104-5.1.x86_64 lftp-4.7.4-2.6.1.x86_64
Good point, I hadn't considered ftp. But the clients I've used are a bit cumbersome to use when transferring thousands of large files thither and yon. I've got spoiled users and they've gotten used to pre-placed ssh pubic keys. I'll take a look at your referenced clients, maybe they allow no-prompt logins to anonymous accounts? Thanks, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
unison might be helpful
http://www.cis.upenn.edu/~bcpierce/unison/
--
Later,
Darin
On Thu, Aug 29, 2019 at 3:42 PM Lew Wolfgang
On 8/29/19 12:18 PM, ken wrote:
On 8/29/19 2:16 PM, Lew Wolfgang wrote:
Hi Folks,
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Maybe wrap netcat up with some scripts?
Maybe rsync could be persuaded to use netcat?
Byte the bullet and learn munge?
Any other options? ftp
$ rpm -qf /usr/bin/ftp tnftp-20141104-5.1.x86_64 lftp-4.7.4-2.6.1.x86_64
Good point, I hadn't considered ftp. But the clients I've used are a bit cumbersome to use when transferring thousands of large files thither and yon. I've got spoiled users and they've gotten used to pre-placed ssh pubic keys. I'll take a look at your referenced clients, maybe they allow no-prompt logins to anonymous accounts?
Thanks, Lew
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 29/08/2019 22.02, Darin Perusich wrote:
unison might be helpful http://www.cis.upenn.edu/~bcpierce/unison/
Uses ssh to do the actual transfer. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Lew Wolfgang wrote:
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
We looked into this some years back, with exactly the same reasoning. AFAIR, the best option was instructing ssh to use some low-quality (ie. cheap) cipher. In the end we didn't bother - there's some extra load on the CPU on both ends, but nothing worth mentioning. Other options - nfs, iscsi? -- Per Jessen, Zürich (19.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 12:21 PM, Per Jessen wrote:
Lew Wolfgang wrote:
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off. We looked into this some years back, with exactly the same reasoning. AFAIR, the best option was instructing ssh to use some low-quality (ie. cheap) cipher.
In the end we didn't bother - there's some extra load on the CPU on both ends, but nothing worth mentioning.
Other options - nfs, iscsi?
Hmm... iscsi? I might have to take a look. We still use nfs, but from distant past experience there's quite a performance hit. I'll revisit and run some tests. BTW, using classic rcp we were able to get about 80% of wire-speed on a 10-GbE connection, but only about 30% when using scp. I'm assuming that encryption is the big driver here. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 8/29/19 12:21 PM, Per Jessen wrote:
Lew Wolfgang wrote:
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off. We looked into this some years back, with exactly the same reasoning. AFAIR, the best option was instructing ssh to use some low-quality (ie. cheap) cipher.
In the end we didn't bother - there's some extra load on the CPU on both ends, but nothing worth mentioning.
Other options - nfs, iscsi?
Hmm... iscsi? I might have to take a look.
We still use nfs, but from distant past experience there's quite a performance hit. I'll revisit and run some tests.
These days, nfs4 and iscsi are much the same. I just have a penchant for iscsi, and maybe handing off some of the load to hardware does help We don't have 10GbE yet, only 1GbE - offloading to the network card at least take a load off the CPU. (okay, gut feeling, I have not measured it).
BTW, using classic rcp we were able to get about 80% of wire-speed on a 10-GbE connection, but only about 30% when using scp. I'm assuming that encryption is the big driver here.
Wow, that's a _major_ drop. If it were me, I'd look at all the numbers. A 50% drop by the CPU(s) not being able to process the data fast enough? How about building rcp from source? or writing your own. -- Per Jessen, Zürich (20.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 1:30 PM, Per Jessen wrote:
How about building rcp from source? or writing your own.
:-D My last program was an interrupt-driven assembly-code CRT driver for the TurboDos operating system on a Z-80 "boat anchor for a power supply" S100 bus system! They had all of 64-KB of ram too! But they also had real mahogany wood trim, everybody wanted one... mrsh with munge is starting to look better. Maybe I should actually take a look at it? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 1:45 PM, Lew Wolfgang wrote:
On 8/29/19 1:30 PM, Per Jessen wrote:
How about building rcp from source? or writing your own.
:-D My last program was an interrupt-driven assembly-code CRT driver for the TurboDos operating system on a Z-80 "boat anchor for a power supply" S100 bus system! They had all of 64-KB of ram too! But they also had real mahogany wood trim, everybody wanted one...
mrsh with munge is starting to look better. Maybe I should actually take a look at it?
A co-worker googled a bit and found NFS/RDMA over RoCE. It's basically NFS using Ethernet adapters that do remote DMA transfers. NFS would transfer from server to client without the CPU's on either end being involved. Sounds like fun! BTW, it looks like Leap 15.1 supports RDMA. https://blog.mellanox.com/2018/06/double-your-network-file-system-performanc... Just google nfs rdma. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 8/29/19 1:45 PM, Lew Wolfgang wrote:
On 8/29/19 1:30 PM, Per Jessen wrote:
How about building rcp from source? or writing your own.
:-D My last program was an interrupt-driven assembly-code CRT driver for the TurboDos operating system on a Z-80 "boat anchor for a power supply" S100 bus system! They had all of 64-KB of ram too! But they also had real mahogany wood trim, everybody wanted one...
mrsh with munge is starting to look better. Maybe I should actually take a look at it?
A co-worker googled a bit and found NFS/RDMA over RoCE. It's basically NFS using Ethernet adapters that do remote DMA transfers. NFS would transfer from server to client without the CPU's on either end being involved. Sounds like fun!
BTW, it looks like Leap 15.1 supports RDMA.
It does sound like a lot of fun - never heard of it. When you're talking 40GbE, I guess you have the network adapters to match :-) -- Per Jessen, Zürich (18.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 29/08/2019 14:16, Lew Wolfgang wrote:
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Well SSH can be set up so that the login, while a key exchange, is done transparently & automagically for that 'known host'. This sounds simpler and is well documented, plenty of examples in help files. Abut as complicated as the use of .rhosts. I'd choose it over 'munge'. I think the option you are talking about is the one that lets you choose what encryption protocol to use for the data transfer after the authentication is done. Choose 'plain text'. I think you want -c cipher_spec Selects the cipher specification for encrypting the session. see also SSH_CONFIG(5) THEN try and find the patch that lets you select 'plain text'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 12:23 PM, Anton Aylward wrote:
SSH insists on encryption, but there are apparently patches that will allow it to be turned off. Well SSH can be set up so that the login, while a key exchange, is done transparently & automagically for that 'known host'. This sounds simpler and is well documented, plenty of examples in help files. Abut as complicated as the use of .rhosts. I'd choose it over 'munge'.
I think the option you are talking about is the one that lets you choose what encryption protocol to use for the data transfer after the authentication is done. Choose 'plain text'.
I think you want -c cipher_spec Selects the cipher specification for encrypting the session.
see also SSH_CONFIG(5) THEN try and find the patch that lets you select 'plain text'.
Yes, we use pre-placed public ssh keys for logins. I've never mucked with munge. I don't believe that you can use "none" in sshd without enabling it in source and recompiling. There are some patches that do this, but still require recompilation. That's always an option I guess... Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
I don't believe that you can use "none" in sshd without enabling it in source and recompiling. There are some patches that do this, but still require recompilation. That's always an option I guess...
I'll check tomorrow, but I think that is where we got stuck too. Mind you, if you have a true desire, it sounds entirely feasible. -- Per Jessen, Zürich (19.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 29/08/2019 16:06, Lew Wolfgang wrote:
I don't believe that you can use "none" in sshd without enabling it in source and recompiling. There are some patches that do this, but still require recompilation. That's always an option I guess...
Please see https://tools.ietf.org/html/rfc4252#page-7 If you run ssh -Q cipher to see what you have, you will NOT see 'none' liisted there. This is in accordance with the spec: 5.2. The "none" Authentication Request ... This 'method name' MUST NOT be listed as supported by the server. But it might well be there, and the rest of that stanza says: A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'. If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. "Suck it and see." -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 29/08/2019 20:34, Anton Aylward wrote:
On 29/08/2019 16:06, Lew Wolfgang wrote:
I don't believe that you can use "none" in sshd without enabling it in source and recompiling. There are some patches that do this, but still require recompilation. That's always an option I guess...
Please see https://tools.ietf.org/html/rfc4252#page-7
If you run ssh -Q cipher to see what you have, you will NOT see 'none' liisted there. This is in accordance with the spec:
5.2. The "none" Authentication Request ... This 'method name' MUST NOT be listed as supported by the server.
But it might well be there, and the rest of that stanza says:
A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'.
If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS.
More from the spec: Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, *unless* the client is to be granted access without any authentication, in which case, the server MUST accept this request. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/29/19 5:53 PM, Anton Aylward wrote:
On 29/08/2019 20:34, Anton Aylward wrote:
On 29/08/2019 16:06, Lew Wolfgang wrote:
I don't believe that you can use "none" in sshd without enabling it in source and recompiling. There are some patches that do this, but still require recompilation. That's always an option I guess... Please see https://tools.ietf.org/html/rfc4252#page-7
If you run ssh -Q cipher to see what you have, you will NOT see 'none' liisted there. This is in accordance with the spec:
5.2. The "none" Authentication Request ... This 'method name' MUST NOT be listed as supported by the server.
But it might well be there, and the rest of that stanza says:
A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'.
If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS.
More from the spec:
Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, *unless* the client is to be granted access without any authentication, in which case, the server MUST accept this request.
That's interesting, Anton. But does the Authentication method also govern the cipher used for data in flight encryption? I'll have to try it. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Lew Wolfgang
Hi Folks,
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Maybe wrap netcat up with some scripts?
Maybe rsync could be persuaded to use netcat?
Byte the bullet and learn munge?
Any other options?
lftp is pretty simple and easy supports shell cmds, bookmarks, alises, ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
29.08.2019 21:16, Lew Wolfgang пишет:
Hi Folks,
We've been using rsh, and rsync calling rsh, to transfer large files over local network links to avoid the encrypt/decrypt overhead. I know about the security concerns, but these transfers are completely local on isolated networks.
In preparation for deploying a 40GbE link I noticed that rsh isn't supported on Leap 15 and up. There's a replacement called mrsh that uses something called munge for authentication. Bummer. I'd rather not have to figure this all out when authentication isn't needed in the first place.
So, what are the options for sending many large files between machines without encryption?
SSH insists on encryption, but there are apparently patches that will allow it to be turned off.
Maybe wrap netcat up with some scripts?
Maybe rsync could be persuaded to use netcat?
Byte the bullet and learn munge?
Any other options?
Just use rsync directly, without any rsh/ssh. rsync foo server::bar -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer! -- Per Jessen, Zürich (18.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another. I did not know this was not encrypted transfer. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another.
He's been doing that all the time (rshd)
I did not know this was not encrypted transfer.
rsync has never had encryption. It's add on via ssh and such. regards, -- /bengan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/29/2019 11:57 PM, Bengt Gördén wrote:
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another.
He's been doing that all the time (rshd)
I did not know this was not encrypted transfer.
rsync has never had encryption. It's add on via ssh and such.
Interesting! I never thought of running the rsync daemon. It would have to be running on all of our hosts to mimic our current setup, and the "modules" would have to be figured out. I guess that if authentication is enabled, that username/passwords are sent in the clear, right? They'd also have to be stored in clear-text on each end. That would be okay in our insular use case. OTOH, it might be easier to figure out munge and go with mrsh? Thanks for all the ideas! Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 10:40, Lew Wolfgang wrote:
OTOH, it might be easier to figure out munge and go with mrsh?
I think not. As far as I can tell its just another certificate/authentication system. SSH is well documented, and I found it remarkable easy to set up for certificate based transparent login. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 30/08/2019 10:40, Lew Wolfgang wrote:
OTOH, it might be easier to figure out munge and go with mrsh?
I think not. As far as I can tell its just another certificate/authentication system. SSH is well documented, and I found it remarkable easy to set up for certificate based transparent login.
I think maybe you have overlooked $SUBJ - to maximise thruput Lew wants to avoid ssh. -- Per Jessen, Zürich (27.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 11:33, Per Jessen wrote:
Anton Aylward wrote:
On 30/08/2019 10:40, Lew Wolfgang wrote:
OTOH, it might be easier to figure out munge and go with mrsh?
I think not. As far as I can tell its just another certificate/authentication system. SSH is well documented, and I found it remarkable easy to set up for certificate based transparent login.
I think maybe you have overlooked $SUBJ - to maximise thruput Lew wants to avoid ssh.
Let's assume that he ignores all the "none" options. There's a variety of different encryption algorithms available; obviously the 'overhead' will depend on which one is used. So how does 'ssh' compare to 'telnet'? https://superuser.com/questions/1108165/what-is-the-overhead-of-ssh-compared... - Yes and no. There is a rekeying after 1 GB of data or 1 hour of connection time. Can also depend on whether keys are used for authentication. Diffie- Hellman is generally more expensive than RSA key exchange, but since it only happens once(ish) not a big deal. - Yes there is overhead: you have to add random padding of at least 4 byte (SSH2) And each data package gets an HMAC of some sort. Depending on what is used. I don't know how much exactly but it is less at max 33 byte (Full sha2 length) Max payload is 35000 - 4 byte padding. You get about 37/34996 = 0.001 % overhead or less. - CPU overhead is minimal. That was one of the goals for AES standard. Same here. It is roughly symmetrical since the crypto operations are .- - If someone blasts a 1 GBit connection at you and copies 10 GB of data via scp: using a standard intel i7 probably two or three at a time. Its likely that your NIC or storage bottle necks first. I note that answer says nothing about buffer size; I'd have thought that would be a factor. It certainly will be if you use 'netcat', but then again, perhaps you also need to 'tune" the TCP buffers and latency. Oh, right, 'latency'! Of course there's also https://superuser.com/questions/326211/best-way-to-transfer-files-over-a-lan... This https://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/ has nice graphs comparing the various encryption methods. HOWEVER, that's with old hardware. Modern cpus come with instruction sets and microcode that facilitate the implementation of AES: https://possiblelossofprecision.net/?p=2255 The article also makes the point that the receiving system's filesystem and buffers and the way it updates can also affect overall performance. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 08:05 PM, Anton Aylward wrote:
I think maybe you have overlooked $SUBJ - to maximise thruput Lew wants to avoid ssh. Let's assume that he ignores all the "none" options.
He reseached the "none" option and none were available. Would that they were by default.
There's a variety of different encryption algorithms available; obviously the 'overhead' will depend on which one is used.
I tested scp against rcp in my admittedly limited use case, and found that scp ran at about 50% of rcp's speed (IIRC). Granted, a limited use case, but valid nevertheless. Depending on what my users are doing, rcp saves them, literally, days of time. Yes, they use rsync too, and specify rsh instead of the default ssh for the remote shell. Why the speed difference? I assumed it was scp's encryption, but I admit it could be other things. It doesn't matter, it is what it is, and I can't use classic rcp starting with Leap 15. Ergo, this thread. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 23:36, Lew Wolfgang wrote:
On 08/30/2019 08:05 PM, Anton Aylward wrote:
I think maybe you have overlooked $SUBJ - to maximise thruput Lew wants to avoid ssh. Let's assume that he ignores all the "none" options.
He reseached the "none" option and none were available. Would that they were by default.
Who is the "he" in the above clause? I researched it, read up the RFC, experimented and found the option did exist, and did work. This is anton@main:~> ssh -V OpenSSH_7.2p2, OpenSSL 1.0.2j-fips 26 Sep 2016 as per the # zypper info openssh Information for package openssh: -------------------------------- Repository : openSUSE-Leap-42.3-Update Name : openssh Version : 7.2p2-35.1 Arch : x86_64 Vendor : openSUSE Installed Size : 5.7 MiB Installed : Yes Status : up-to-date Source package : openssh-7.2p2-35.1.src -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 08:48 PM, Anton Aylward wrote:
On 30/08/2019 23:36, Lew Wolfgang wrote:
I think maybe you have overlooked $SUBJ - to maximise thruput Lew wants to avoid ssh. Let's assume that he ignores all the "none" options. He reseached the "none" option and none were available. Would
On 08/30/2019 08:05 PM, Anton Aylward wrote: that they were by default. Who is the "he" in the above clause?
He is me. I was following your lead. Definitely time to move this to offtopic. This is my last reply. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/08/2019 05.36, Lew Wolfgang wrote: ....
I tested scp against rcp in my admittedly limited use case, and found that scp ran at about 50% of rcp's speed (IIRC). Granted, a limited use case, but valid nevertheless. Depending on what my users are doing, rcp saves them, literally, days of time. Yes, they use rsync too, and specify rsh instead of the default ssh for the remote shell.
Why the speed difference? I assumed it was scp's encryption, but I admit it could be other things. It doesn't matter, it is what it is, and I can't use classic rcp starting with Leap 15. Ergo, this thread.
Maybe you hit the speed difference because your network is so fast, and ours is not. Interesting! Small test here: cer@Telcontar:~/tmp/ssh> scp cer@isengard:Laura01.mp4 . Laura01.mp4 100% 472MB 42.5MB/s 00:11 cer@Telcontar:~/tmp/ssh> Well, it is a gigabit network, it should be twice as fast. One CPU core goes almost 100% on both server and client, so the app is expensive and doesn't maximize network speed. Let's try using the rsync daemon instead. cer@Telcontar:~/tmp/ssh> rsync --stats --password-file=/home/cer/Cripta/keys/rsync.secrets cer@Isengard.valinor::Videos/Stratton.mpeg . Number of files: 1 (reg: 1) Number of created files: 1 (reg: 1) Number of deleted files: 0 Number of regular files transferred: 1 Total file size: 8,058,862,896 bytes Total transferred file size: 8,058,862,896 bytes Literal data: 8,058,862,896 bytes Matched data: 0 bytes File list size: 39 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 43 Total bytes received: 8,060,830,473 sent 43 bytes received 8,060,830,473 bytes 89,069,950.45 bytes/sec total size is 8,058,862,896 speedup is 1.00 cer@Telcontar:~/tmp/ssh> Ie, 89MB/sec, about double the speed. Why can't you use rcp? Maybe you said it and I missed or forgot. cer@Telcontar:~> rcp If 'rcp' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf rcp cer@Telcontar:~> cnf rcp The program 'rcp' can be found in the following package: * mrsh-rsh-compat [ path: /usr/bin/rcp, repository: zypp (download.opensuse.org-oss) ] Try installing with: sudo zypper install mrsh-rsh-compat cer@Telcontar:~> So it is in another package that I have not installed. Doesn't it work? Or is it that it uses some new authentication method you don't like, that munge thing? About ssh. I understand that Anton says that cypher none exists but is not listed. So I tried: cer@Telcontar:~/tmp/ssh> scp usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 cer@Telcontar:~/tmp/ssh> scp cer@isengard:messages . messages 100% 2642KB 33.5MB/s 00:00 cer@Telcontar:~/tmp/ssh> scp -c none cer@isengard:messages . Unknown cipher type 'none' cer@Telcontar:~/tmp/ssh> -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 08/31/2019 01:28 PM, Carlos E. R. wrote:
On 31/08/2019 05.36, Lew Wolfgang wrote:
....
I tested scp against rcp in my admittedly limited use case, and found that scp ran at about 50% of rcp's speed (IIRC). Granted, a limited use case, but valid nevertheless. Depending on what my users are doing, rcp saves them, literally, days of time. Yes, they use rsync too, and specify rsh instead of the default ssh for the remote shell.
Why the speed difference? I assumed it was scp's encryption, but I admit it could be other things. It doesn't matter, it is what it is, and I can't use classic rcp starting with Leap 15. Ergo, this thread. Maybe you hit the speed difference because your network is so fast, and ours is not. Interesting!
My test was with direct 10-GbE nic-to-nic connections. No switch was in the path. The machines were server-class Supermicros, with Intel nics.
Small test here:
cer@Telcontar:~/tmp/ssh> scp cer@isengard:Laura01.mp4 . Laura01.mp4 100% 472MB 42.5MB/s 00:11 cer@Telcontar:~/tmp/ssh>
Well, it is a gigabit network, it should be twice as fast. One CPU core goes almost 100% on both server and client, so the app is expensive and doesn't maximize network speed. Let's try using the rsync daemon instead.
cer@Telcontar:~/tmp/ssh> rsync --stats --password-file=/home/cer/Cripta/keys/rsync.secrets cer@Isengard.valinor::Videos/Stratton.mpeg .
Number of files: 1 (reg: 1) Number of created files: 1 (reg: 1) Number of deleted files: 0 Number of regular files transferred: 1 Total file size: 8,058,862,896 bytes Total transferred file size: 8,058,862,896 bytes Literal data: 8,058,862,896 bytes Matched data: 0 bytes File list size: 39 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 43 Total bytes received: 8,060,830,473
sent 43 bytes received 8,060,830,473 bytes 89,069,950.45 bytes/sec total size is 8,058,862,896 speedup is 1.00 cer@Telcontar:~/tmp/ssh>
Ie, 89MB/sec, about double the speed.
That's interesting! I wonder what shell you're using? openSUSE's rsync defaults to ssh, right? So rsync and rcp should be about the same, I'd think. I'll have to fiddle around some more.
Why can't you use rcp? Maybe you said it and I missed or forgot.
cer@Telcontar:~> rcp If 'rcp' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf rcp cer@Telcontar:~> cnf rcp
The program 'rcp' can be found in the following package: * mrsh-rsh-compat [ path: /usr/bin/rcp, repository: zypp (download.opensuse.org-oss) ]
Try installing with: sudo zypper install mrsh-rsh-compat
cer@Telcontar:~>
So it is in another package that I have not installed. Doesn't it work? Or is it that it uses some new authentication method you don't like, that munge thing?
Yes, the munge thing is required in Leap 15 and up. I was using standard rsh before.
About ssh. I understand that Anton says that cypher none exists but is not listed. So I tried:
cer@Telcontar:~/tmp/ssh> scp usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 cer@Telcontar:~/tmp/ssh> scp cer@isengard:messages . messages 100% 2642KB 33.5MB/s 00:00 cer@Telcontar:~/tmp/ssh> scp -c none cer@isengard:messages . Unknown cipher type 'none' cer@Telcontar:~/tmp/ssh>
This is what I saw too. There are still some mysteries lurking about here somewhere... Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/08/2019 22.47, Lew Wolfgang wrote:
On 08/31/2019 01:28 PM, Carlos E. R. wrote:
On 31/08/2019 05.36, Lew Wolfgang wrote:
....
I tested scp against rcp in my admittedly limited use case, and found that scp ran at about 50% of rcp's speed (IIRC). Granted, a limited use case, but valid nevertheless. Depending on what my users are doing, rcp saves them, literally, days of time. Yes, they use rsync too, and specify rsh instead of the default ssh for the remote shell.
Why the speed difference? I assumed it was scp's encryption, but I admit it could be other things. It doesn't matter, it is what it is, and I can't use classic rcp starting with Leap 15. Ergo, this thread. Maybe you hit the speed difference because your network is so fast, and ours is not. Interesting!
My test was with direct 10-GbE nic-to-nic connections. No switch was in the path. The machines were server-class Supermicros, with Intel nics.
As I thought.
Small test here:
cer@Telcontar:~/tmp/ssh> scp cer@isengard:Laura01.mp4 . Laura01.mp4 100% 472MB 42.5MB/s 00:11 cer@Telcontar:~/tmp/ssh>
Well, it is a gigabit network, it should be twice as fast. One CPU core goes almost 100% on both server and client, so the app is expensive and doesn't maximize network speed. Let's try using the rsync daemon instead.
cer@Telcontar:~/tmp/ssh> rsync --stats --password-file=/home/cer/Cripta/keys/rsync.secrets cer@Isengard.valinor::Videos/Stratton.mpeg .
...
Ie, 89MB/sec, about double the speed.
That's interesting! I wonder what shell you're using? openSUSE's rsync defaults to ssh, right? So rsync and rcp should be about the same, I'd think. I'll have to fiddle around some more.
No shell. This is using the rsync daemon at the other end. See the double colon on the command?
Why can't you use rcp? Maybe you said it and I missed or forgot. ... So it is in another package that I have not installed. Doesn't it work? Or is it that it uses some new authentication method you don't like, that munge thing?
Yes, the munge thing is required in Leap 15 and up. I was using standard rsh before.
Ah.
About ssh. I understand that Anton says that cypher none exists but is not listed. So I tried:
cer@Telcontar:~/tmp/ssh> scp usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 cer@Telcontar:~/tmp/ssh> scp cer@isengard:messages . messages 100% 2642KB 33.5MB/s 00:00 cer@Telcontar:~/tmp/ssh> scp -c none cer@isengard:messages . Unknown cipher type 'none' cer@Telcontar:~/tmp/ssh>
This is what I saw too.
There are still some mysteries lurking about here somewhere...
Maybe "none" has to be enabled at the other end first - which I will not do, it faces outside that machine. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 08/31/2019 01:59 PM, Carlos E. R. wrote:
cer@Telcontar:~/tmp/ssh> rsync --stats --password-file=/home/cer/Cripta/keys/rsync.secrets cer@Isengard.valinor::Videos/Stratton.mpeg . ... Ie, 89MB/sec, about double the speed. That's interesting! I wonder what shell you're using? openSUSE's rsync defaults to ssh, right? So rsync and rcp should be about the same, I'd think. I'll have to fiddle around some more. No shell. This is using the rsync daemon at the other end. See the double colon on the command?
Roger! I didn't notice, it makes sense now. scp gives about 1/2 the throughput as a non-encrypted stream. Consistent with my observations.
About ssh. I understand that Anton says that cypher none exists but is not listed. So I tried:
cer@Telcontar:~/tmp/ssh> scp usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 cer@Telcontar:~/tmp/ssh> scp cer@isengard:messages . messages 100% 2642KB 33.5MB/s 00:00 cer@Telcontar:~/tmp/ssh> scp -c none cer@isengard:messages . Unknown cipher type 'none' cer@Telcontar:~/tmp/ssh>
This is what I saw too.
There are still some mysteries lurking about here somewhere... Maybe "none" has to be enabled at the other end first - which I will not do, it faces outside that machine.
I think that's the rub: "none" isn't available unless sshd is patched and re-compiled. I still don't understand how Anton can do it with his Dreamhost account. I look forward to his report after he examines his data stream. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
30.08.2019 17:40, Lew Wolfgang пишет:
On 08/29/2019 11:57 PM, Bengt Gördén wrote:
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another.
He's been doing that all the time (rshd)
I did not know this was not encrypted transfer.
rsync has never had encryption. It's add on via ssh and such.
Interesting! I never thought of running the rsync daemon. It would have to be running on all of our hosts to mimic our current setup, and the "modules" would have to be figured out. I guess that if authentication is enabled, that username/passwords are sent in the clear, right? They'd also have to be stored in clear-text on each end. That would be okay in our insular use case.
OTOH, it might be easier to figure out munge and go with mrsh?
It does not look like there is much to do - you just need to setup common secret on all your servers, everything else is up to clients using munge. Note that MIT Kerberos also includes r* clients. So if you use Kerberos, you already have everything you need. Setting up Kerberos from scratch is probably more challenging than munge.
Thanks for all the ideas!
Regards, Lew
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 16.40, Lew Wolfgang wrote:
On 08/29/2019 11:57 PM, Bengt Gördén wrote:
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another.
He's been doing that all the time (rshd)
I did not know this was not encrypted transfer.
rsync has never had encryption. It's add on via ssh and such.
Interesting! I never thought of running the rsync daemon. It would have to be running on all of our hosts to mimic our current setup, and the "modules" would have to be figured out. I guess that if authentication is enabled, that username/passwords are sent in the clear, right?
They are not the account passwords, they are either typed or kept on separate files on both server and client. I don't know if they are sent on the clear or not.
They'd also have to be stored in clear-text on each end. That would be okay in our insular use case.
With permissions to read only by user. And can be kept on encrypted partition, so not accessible off-line. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 08/30/2019 11:06 AM, Carlos E. R. wrote:
On 30/08/2019 16.40, Lew Wolfgang wrote:
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another. He's been doing that all the time (rshd)
I did not know this was not encrypted transfer. rsync has never had encryption. It's add on via ssh and such. Interesting! I never thought of running the rsync daemon. It would have to be running on all of our hosts to mimic our current setup, and the "modules" would have to be
On 08/29/2019 11:57 PM, Bengt Gördén wrote: figured out. I guess that if authentication is enabled, that username/passwords are sent in the clear, right? They are not the account passwords, they are either typed or kept on separate files on both server and client. I don't know if they are sent on the clear or not.
Ah, so used this way the rsync server is functioning like an ftp server. Our usage case with ssh and rsh (in the enclave) is for users to read/write in their home directories, or common areas with suitable permissions. Again, maybe pre-placed secrets with munge is the easiest way forward? BTW, I checked and the 40-GbE interfaces we have don't support iWARP, so nfs via rdma won't work unless we update our NIC's. I'm sure I can convince management to purchase some, I'll report my progress here as time goes by. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 21.18, Lew Wolfgang wrote:
On 08/30/2019 11:06 AM, Carlos E. R. wrote:
On 30/08/2019 16.40, Lew Wolfgang wrote:
On 2019-08-30 08:36, Carlos E. R. wrote:
Well, you have to run the daemon on one end and the application on another. He's been doing that all the time (rshd)
I did not know this was not encrypted transfer. rsync has never had encryption. It's add on via ssh and such. Interesting! I never thought of running the rsync daemon. It would have to be running on all of our hosts to mimic our current setup, and the "modules" would have to be
On 08/29/2019 11:57 PM, Bengt Gördén wrote: figured out. I guess that if authentication is enabled, that username/passwords are sent in the clear, right? They are not the account passwords, they are either typed or kept on separate files on both server and client. I don't know if they are sent on the clear or not.
Ah, so used this way the rsync server is functioning like an ftp server.
Yep. With extra features, like sending changes to a file instead of the entire file. Can be useful on a broken upload.
Our usage case with ssh and rsh (in the enclave) is for users to read/write in their home directories, or common areas with suitable permissions. Again, maybe pre-placed secrets with munge is the easiest way forward?
I don't know.
BTW, I checked and the 40-GbE interfaces we have don't support iWARP, so nfs via rdma won't work unless we update our NIC's. I'm sure I can convince management to purchase some, I'll report my progress here as time goes by.
Will be interesting. I guess at those speeds the CPU involvement becomes important? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 30/08/2019 15:18, Lew Wolfgang wrote:
Again, maybe pre-placed secrets with munge is the easiest way forward?
And what about 'pre-placed secrets' using 'ssh-copy-id'? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
30.08.2019 22:18, Lew Wolfgang пишет:
BTW, I checked and the 40-GbE interfaces we have don't support iWARP, so nfs via rdma won't work unless we update our NIC's. I'm sure I can convince management to purchase some, I'll report my progress here as time goes by.
There are two (well, more if counting versions) RDMA over Ethernet protocols - iWARP and ROCE(v2). Your adapters may support the latter. ROCE places more demands on infrastructure (requiring by definition Converged Ethernet). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 30/08/2019 à 08:36, Carlos E. R. a écrit :
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another.
no necessity to run the daemon, it only makes things better jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 30/08/2019 à 08:36, Carlos E. R. a écrit :
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another.
no necessity to run the daemon, it only makes things better
Uh no, when you are not using ssh, you have to run the daemon. -- Per Jessen, Zürich (19.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 03:43, Per Jessen wrote:
jdd@dodin.org wrote:
Le 30/08/2019 à 08:36, Carlos E. R. a écrit :
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another.
no necessity to run the daemon, it only makes things better
Uh no, when you are not using ssh, you have to run the daemon.
Yes/no/maybe. The issue is having a tunnel of some sort between the source and destination that rsync can use. That applies whether or not you have a daemon/server at the other end. rsh, ssh, netcat ... whatever. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 09.33, jdd@dodin.org wrote:
Le 30/08/2019 à 08:36, Carlos E. R. a écrit :
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another.
no necessity to run the daemon, it only makes things better
For storing files remotely without using ssh, yes, you need it. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 30/08/2019 03:33, jdd@dodin.org wrote:
Le 30/08/2019 à 08:36, Carlos E. R. a écrit :
On 30/08/2019 08.16, Per Jessen wrote:
Andrei Borzenkov wrote:
Just use rsync directly, without any rsh/ssh.
rsync foo server::bar
Yes, of course - I knew there was a simple answer!
Well, you have to run the daemon on one end and the application on another.
no necessity to run the daemon, it only makes things better
Right. I build a web site locally and then rsync the whole thing to my location at Dreamhost. There's no server at my account the other end, just the certificate stuff for the login. But I gather that you lave, Lew, that certificate stuff in place yourself anyway. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 08:19 AM, Anton Aylward wrote:
no necessity to run the daemon, it only makes things better Right. I build a web site locally and then rsync the whole thing to my location at Dreamhost. There's no server at my account the other end, just the certificate stuff for the login.
But Anton, you need to have some sort of a server on the other end. rsync uses ssh by default, to the best of my knowledge. And once you're using ssh, you can't turn off encryption on the established tunnel unless you're using a patched ssh. Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to?
But I gather that you lave, Lew, that certificate stuff in place yourself anyway.
Yes, we have the appropriate public ssh keys in place for ssh logins. We don't use those, of course, for the rsh logins. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 12:25, Lew Wolfgang wrote:
Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to?
Yes it does, that was the point I was making. I simply type "ssh antonaylward.com" and I'm logged in. I had generated the certificate locally as per the SSH manual, then I 'push' it using 'ssh-copy-id'. Once that's in place all the SSH operations are "automatic login". As for the use of 'no encryption', see earlier posts. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 07:44 PM, Anton Aylward wrote:
On 30/08/2019 12:25, Lew Wolfgang wrote:
Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to?
Yes it does, that was the point I was making.
I simply type "ssh antonaylward.com" and I'm logged in.
I had generated the certificate locally as per the SSH manual, then I 'push' it using 'ssh-copy-id'. Once that's in place all the SSH operations are "automatic login".
As for the use of 'no encryption', see earlier posts.
Yup, once you use ssh you're stuck with full encryption by design, unless you find binary patches or recompile. I really don't want to do that due to maintainability issues with updates. BTW, did you disable username/password logins on your Dreamhost account? It's "best practice" for a public facing ssh server. You might also deny connection attempts from all IP's except your own remote client. Do you have that level of control with your Dreamhost account? Do you have a VPS or dedicated server? If so, how do you like it? Can you install your own OS through a KVM/IP connection, or do you have use what they give you? Can you "Leap" to your operating system of choice? Is this thread wandering into offtopic territory? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/08/2019 23:21, Lew Wolfgang wrote:
On 08/30/2019 07:44 PM, Anton Aylward wrote:
On 30/08/2019 12:25, Lew Wolfgang wrote:
Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to?
Yes it does, that was the point I was making.
I simply type "ssh antonaylward.com" and I'm logged in.
I had generated the certificate locally as per the SSH manual, then I 'push' it using 'ssh-copy-id'. Once that's in place all the SSH operations are "automatic login".
As for the use of 'no encryption', see earlier posts.
Yup, once you use ssh you're stuck with full encryption by design, unless you find binary patches or recompile.
Please see my earlier posts. Yes, using ssh -c none antonaylward.com gives me a shh connection without encryption.
BTW, did you disable username/password logins on your Dreamhost account?
Yes.
It's "best practice" for a public facing ssh server. You might also deny connection attempts from all IP's except your own remote client.
no. My home system is with an ISP that assigns IP adress using DHCP. My address changes periodically.
Do you have that level of control with your Dreamhost account?
Yes, but see above.
Do you have a VPS or dedicated server?
I have a 'shared service'. I could have a any of the above and more but it would cost a lot more. I'm mostly concerned with storage and email, and that's what I get and I'm happy.
If so, how do you like it? Can you install your own OS through a KVM/IP connection, or do you have use what they give you?
If I chose to pay for a dedicated virtual machine option they yes to the above and more. lew, I suggest you visit the Dreamhost site and see their offerings. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/30/2019 08:41 PM, Anton Aylward wrote:
On 30/08/2019 23:21, Lew Wolfgang wrote:
On 08/30/2019 07:44 PM, Anton Aylward wrote:
On 30/08/2019 12:25, Lew Wolfgang wrote:
Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to? Yes it does, that was the point I was making.
I simply type "ssh antonaylward.com" and I'm logged in.
I had generated the certificate locally as per the SSH manual, then I 'push' it using 'ssh-copy-id'. Once that's in place all the SSH operations are "automatic login".
As for the use of 'no encryption', see earlier posts. Yup, once you use ssh you're stuck with full encryption by design, unless you find binary patches or recompile. Please see my earlier posts.
Yes, using ssh -c none antonaylward.com
gives me a shh connection without encryption.
When I do that I get a fully encrypted connection along with this message for one of my servers: "No valid ciphers for protocol version 2 given, using defaults." Another client/server (both Leap 15.1) says: "Unknown cypher type "none"" When I do this I get: ssh -c none antonaylward.com No valid ciphers for protocol version 2 given, using defaults. The authenticity of host 'antonaylward.com (66.33.210.248)' can't be established. ECDSA key fingerprint is d1:ff:32:eb:19:56:52:d2:73:b1xxx [MD5]. Are you sure you want to continue connecting (yes/no)? Do you get the "No valid ciphers" message? If not, did you look at the actual ssh traffic with tcpdump or wireshark to see if it's really unencrypted?
BTW, did you disable username/password logins on your Dreamhost account? Yes.
Great!
It's "best practice" for a public facing ssh server. You might also deny connection attempts from all IP's except your own remote client. no. My home system is with an ISP that assigns IP adress using DHCP. My address changes periodically.
Maybe you could deny by default, allow for your ISP's address range?
Do you have that level of control with your Dreamhost account? Yes, but see above.
Do you have a VPS or dedicated server? I have a 'shared service'. I could have a any of the above and more but it would cost a lot more. I'm mostly concerned with storage and email, and that's what I get and I'm happy.
If so, how do you like it? Can you install your own OS through a KVM/IP connection, or do you have use what they give you? If I chose to pay for a dedicated virtual machine option they yes to the above and more.
lew, I suggest you visit the Dreamhost site and see their offerings.
I'm in the market for a dedicated server and was hoping that you could offer a review of their service. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/08/2019 00:39, Lew Wolfgang wrote:
On 08/30/2019 08:41 PM, Anton Aylward wrote:
On 30/08/2019 23:21, Lew Wolfgang wrote:
On 08/30/2019 07:44 PM, Anton Aylward wrote:
On 30/08/2019 12:25, Lew Wolfgang wrote:
Are you sure that Dreamhost doesn't support ssh logins? What "certificate stuff" are you referring to? Yes it does, that was the point I was making.
I simply type "ssh antonaylward.com" and I'm logged in.
I had generated the certificate locally as per the SSH manual, then I 'push' it using 'ssh-copy-id'. Once that's in place all the SSH operations are "automatic login".
As for the use of 'no encryption', see earlier posts. Yup, once you use ssh you're stuck with full encryption by design, unless you find binary patches or recompile. Please see my earlier posts.
Yes, using ssh -c none antonaylward.com
gives me a shh connection without encryption.
When I do that I get a fully encrypted connection along with this message for one of my servers:
"No valid ciphers for protocol version 2 given, using defaults."
Another client/server (both Leap 15.1) says:
"Unknown cypher type "none""
When I do this I get:
ssh -c none antonaylward.com No valid ciphers for protocol version 2 given, using defaults. The authenticity of host 'antonaylward.com (66.33.210.248)' can't be established. ECDSA key fingerprint is d1:ff:32:eb:19:56:52:d2:73:b1xxx [MD5]. Are you sure you want to continue connecting (yes/no)?
Do you get the "No valid ciphers" message? If not, did you look at the actual ssh traffic with tcpdump or wireshark to see if it's really unencrypted?
Oops, I forgot to mention that I have stuff in my .bash_profile that sets up the environment ... eval $(keychain --nogui --gpg2 --eval --agents "ssh,gpg" id_rsa XXXXX ) and more, and since I'd already done the matching 'ssh-copy-id' .. NO I DO NOT get the "No valid ciphers" message. Only one machine operative at the moment so doing a wireshark will take a bit of setup. I need more coffee before attempting that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Anton Aylward -
Bengt Gördén -
Carlos E. R. -
Darin Perusich -
jdd＠dodin.org -
ken -
Lew Wolfgang -
Patrick Shanahan -
Per Jessen