Linux Services
neil...@gmail.com
replace them with some other secure ones ?
Bit Twister
> why services such as rlogin, rsh, and rexec are dangerous
id/paswords/data passed as clear text.
> and can we replace them with some other secure ones ?
Yes.
scp, sftp, ssh
Chris Davies
> why services such as rlogin, rsh, and rexec are dangerous
Bit Twister <BitTw...@mouse-potato.com> wrote:
> id/paswords/data passed as clear text.
Also, the protocol requires the server to trust that the client is
telling the truth with regard to the username.
Chris
Bit Twister
I also thought there could be a problem trusting the hostname of the
client. :(
Frank Pittel
While I understand that it's stupid to allow a machine to allow rsh
connections from the internet. I do prefer rsh on my internal network
to solutions like ssh.
--
-------------------
Keep working millions on welfare depend on you
General Schvantzkoph
> Chris Davies <chris-...@roaima.co.uk> wrote: : On 23 May 2006
> 01:39:46 -0700, neil...@gmail.com wrote: : > why services such as
> rlogin, rsh, and rexec are dangerous
>
> : Bit Twister <BitTw...@mouse-potato.com> wrote: : > id/paswords/data
> passed as clear text.
>
> : Also, the protocol requires the server to trust that the client is :
> telling the truth with regard to the username.
>
> While I understand that it's stupid to allow a machine to allow rsh
> connections from the internet. I do prefer rsh on my internal network to
> solutions like ssh.
Why use rsh on your internal machines? I'll agree that it's not a security
issue on your LAN but I don't see any advantages to using rsh or rlogin
anymore. I use ssh for everything, it works great. I have all of my
machines set up with each others public keys in their
/etc/ssh/authorized_keys files so I don't need any passwords. SSH handles
cvs, X-forwarding, rsyncing, there isn't anything that it can't do. Also
ssh is always available right out of the box when you do a new install.
Admittedly it's not hard to add the legacy services but there is no reason
to do it anymore.
Robert M. Riches Jr.
(I'm _not_ the OP.)
One disadvantage of scp is the CPU overhead of the
encryption. When copying 2.6GB one way and 1.4GB the other
way over 100Mb ethernet, the CPU is buried so badly handling
the encryption that both systems are useless for anything
else. Without the encryption CPU load, you can actually do
something on the systems while transferring.
--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Michael Heiming
> On 2006-05-23, General Schvantzkoph <schvan...@yahoo.com> wrote:
>> On Tue, 23 May 2006 13:07:21 -0500, Frank Pittel wrote:
>>
>>> Chris Davies <chris-...@roaima.co.uk> wrote: : On 23 May 2006
>>> 01:39:46 -0700, neil...@gmail.com wrote: : > why services such as
>>> rlogin, rsh, and rexec are dangerous
>>>
>>> : Bit Twister <BitTw...@mouse-potato.com> wrote: : > id/paswords/data
>>> passed as clear text.
>>>
>>> : Also, the protocol requires the server to trust that the client is :
>>> telling the truth with regard to the username.
>>>
>>> While I understand that it's stupid to allow a machine to allow rsh
>>> connections from the internet. I do prefer rsh on my internal network to
>>> solutions like ssh.
>>
>> Why use rsh on your internal machines? I'll agree that it's not a security
>> issue on your LAN but I don't see any advantages to using rsh or rlogin
>> anymore. I use ssh for everything, it works great. I have all of my
>> machines set up with each others public keys in their
>> /etc/ssh/authorized_keys files so I don't need any passwords. SSH handles
>> cvs, X-forwarding, rsyncing, there isn't anything that it can't do. Also
>> ssh is always available right out of the box when you do a new install.
Indeed, not talking about the advanced features, port/agent
forwarding through multiple systems in one go and alike. ;-)
[..]
> One disadvantage of scp is the CPU overhead of the
> encryption. When copying 2.6GB one way and 1.4GB the other
> way over 100Mb ethernet, the CPU is buried so badly handling
> the encryption that both systems are useless for anything
> else. Without the encryption CPU load, you can actually do
> something on the systems while transferring.
You could just use another cypher or even none to speed up
operations, and lower CPU usage, authentication will still be
encrypted. "blowfish" usually doesn't use that much CPU.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 205: Quantum dynamics are affecting the transistors
Robert M. Riches Jr.
> In comp.os.linux.misc Robert M. Riches Jr. <spamt...@verizon.net>:
>
>> encryption. When copying 2.6GB one way and 1.4GB the other
>> way over 100Mb ethernet, the CPU is buried so badly handling
>> the encryption that both systems are useless for anything
>> else. Without the encryption CPU load, you can actually do
>> something on the systems while transferring.
>
> You could just use another cypher or even none to speed up
> operations, and lower CPU usage, authentication will still be
> encrypted. "blowfish" usually doesn't use that much CPU.
Thanks for the suggestion. I'll have to give it a try.
General Schvantzkoph
> You could just use another cypher or even none to speed up operations, and
> lower CPU usage, authentication will still be encrypted. "blowfish"
> usually doesn't use that much CPU.
How do you specify no cypher? In the ssh man page I don't see a choice for
no cypher.
Also how do you specify the cypher for rsync and cvs?
Michael Heiming
>>
>> You could just use another cypher or even none to speed up operations, and
>> lower CPU usage, authentication will still be encrypted. "blowfish"
>> usually doesn't use that much CPU.
> How do you specify no cypher? In the ssh man page I don't see a choice for
> no cypher.
Look at the openssh source, as usual 'grep' is your friend. ;-)
> Also how do you specify the cypher for rsync and cvs?
What about the obvious?
rsync ... -e "ssh -c blowfish" ...
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 86: Runt packets
Robert M. Riches Jr.
>>>
>>> You could just use another cypher or even none to speed up operations, and
>>> lower CPU usage, authentication will still be encrypted. "blowfish"
>>> usually doesn't use that much CPU.
>
>> How do you specify no cypher? In the ssh man page I don't see a choice for
>> no cypher.
>
> Look at the openssh source, as usual 'grep' is your friend. ;-)
A few greps of the openssh source indicate 'scp -c none ...'
would be parsed by the command line code, but an attempt at
using it returns the error message
No valid ciphers for protocol version 2 given, using defaults.
On MandrX 2006, copying a 50MB kernel-source RPM file from
one machine to itself uses much less CPU time with blowfish
than with "none":
option user CPU seconds
----------- ----------------
-c blowfish 1.115
-c none 1.919
(blank) 2.006
It would appear '-c none' is not actually useful. I'll
still give blowfish a try.
Thanks.
General Schvantzkoph
> In comp.os.linux.misc General Schvantzkoph <schvan...@yahoo.com>:
>>>
>>> You could just use another cypher or even none to speed up operations,
>>> and lower CPU usage, authentication will still be encrypted. "blowfish"
>>> usually doesn't use that much CPU.
>
>> How do you specify no cypher? In the ssh man page I don't see a choice
>> for no cypher.
>
> Look at the openssh source, as usual 'grep' is your friend. ;-)
>
>> Also how do you specify the cypher for rsync and cvs?
>
> What about the obvious?
>
> rsync ... -e "ssh -c blowfish" ...
How would you set up the env variable? I tried doing a
setenv CVS_RSH "ssh -c blowfish"
but that didn't work.
Michael Heiming
>> In comp.os.linux.misc General Schvantzkoph <schvan...@yahoo.com>:
>>>>
>>>> You could just use another cypher or even none to speed up operations, and
>>>> lower CPU usage, authentication will still be encrypted. "blowfish"
>>>> usually doesn't use that much CPU.
>>
>>> How do you specify no cypher? In the ssh man page I don't see a choice for
>>> no cypher.
>>
>> Look at the openssh source, as usual 'grep' is your friend. ;-)
> A few greps of the openssh source indicate 'scp -c none ...'
> would be parsed by the command line code, but an attempt at
> using it returns the error message
> No valid ciphers for protocol version 2 given, using defaults.
Indeed it doesn't work out of the box, presumingly for security
reasons, you have to enable it in the openssh source and
recompile.
I'd really appreciate if *none* would ask me how to do this. ;-)
> On MandrX 2006, copying a 50MB kernel-source RPM file from
> one machine to itself uses much less CPU time with blowfish
> than with "none":
> option user CPU seconds
> ----------- ----------------
> -c blowfish 1.115
> -c none 1.919
> (blank) 2.006
> It would appear '-c none' is not actually useful. I'll
> still give blowfish a try.
It says it would use defaults. Anyway, thx for taking the five
minutes to actually try something out!
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 254: Interference from lunar radiation
Michael Heiming
> On Tue, 23 May 2006 22:37:36 +0200, Michael Heiming wrote:
>> In comp.os.linux.misc General Schvantzkoph <schvan...@yahoo.com>:
>>> for no cypher.
>>
>> Look at the openssh source, as usual 'grep' is your friend. ;-)
>>
>>> Also how do you specify the cypher for rsync and cvs?
>>
>> What about the obvious?
>>
>> rsync ... -e "ssh -c blowfish" ...
> How would you set up the env variable? I tried doing a
> setenv CVS_RSH "ssh -c blowfish"
> but that didn't work.
You thought about trying the manuals installed on your system?
man ssh_config
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 263: It's stuck in the Web.
General Schvantzkoph
I've tried a number of experiments talking to machines with various speed
connections and CPUs. The configuration factor that makes the most
difference is compression. It either helps or hurts depending on the speed
of the connection. I did all tests from an A64 with an Nforce4 gigabit
ethernet connection. I scped to the following machines,
X2 4400+ with gigabit
Dual Xeon with gigabit
PII 450 with 100bt
PIII 1000 over DSL
When talking gigabit to gigabit compression degrades the transfer rate by
2 to 1.
When talking 100Bt compression helps slightly, about 5%.
When talking DSL compression is a huge win, I saw a 10 to 1 improvement.
Obviously compression only helps if you are transferring something that
hasn't already been compressed. My test case was a 6.8MB tar file. If you
used a tar.gz adding ssh compression would always hurt you.
After compression has been optimized for the different connections the
cipher can make a big difference. I found that the fastest cipher was
arcfour, followed by blowfish. Here are some results transferring between
fast machines, (A64 3800+ to X2 4400+ over gigabit)
3des-cbc 1.57 seconds
aes256-cbc 1.27 seconds
aes192-cbc 1.03 seconds
aes128-cbc .96 seconds
cast128-cbc .86 seconds
blowfish-cbc .74 seconds
arcfour .61 seconds
When going across a 1M DSL line the cypher matters much less,
DSL compression on
aes256-cbc 8.22 seconds
arcfour 7.99 seconds
DSL compression off,
aes256-cbc 81.59 seconds
arcfour 81.78 seconds
Configuring ssh for various machines is done in the ~/.ssh/config file. It
can also be done in /etc/ssh/ssh_config. Here is an example config file.
The Ciphers line orders the choice of cyphers from first choice to last.
Host *
ForwardX11 yes
ForwardX11Trusted yes
StrictHostKeyChecking no
ForwardAgent yes
BatchMode yes
Ciphers arcfour,blowfish-cbc,aes128-cbc,aes256-cbc,aes192-cbc,cast128-cbc,3des-cbc
Host saratoga
Compression no
KeepAlive yes
Host nimitz
Compression no
KeepAlive yes
Host enterprise
Compression no
KeepAlive yes
Host dreadnought
Compression yes
Port 2200
KeepAlive yes
Host darkwing
Compression yes
KeepAlive yes
Robert M. Riches Jr.
> In comp.os.linux.misc Robert M. Riches Jr. <spamt...@verizon.net>:
>> On 2006-05-23, Michael Heiming <michael...@www.heiming.de> wrote:
>>> In comp.os.linux.misc General Schvantzkoph <schvan...@yahoo.com>:
>>>>>
>>>>> You could just use another cypher or even none to speed up operations, and
>>>>> lower CPU usage, authentication will still be encrypted. "blowfish"
>>>>> usually doesn't use that much CPU.
>>>
>>>> How do you specify no cypher? In the ssh man page I don't see a choice for
>>>> no cypher.
>>>
>>> Look at the openssh source, as usual 'grep' is your friend. ;-)
>
>> A few greps of the openssh source indicate 'scp -c none ...'
>> would be parsed by the command line code, but an attempt at
>> using it returns the error message
>
>> No valid ciphers for protocol version 2 given, using defaults.
>
> Indeed it doesn't work out of the box, presumingly for security
> reasons, you have to enable it in the openssh source and
> recompile.
>
> I'd really appreciate if *none* would ask me how to do this. ;-)
Okay, I won't ask how to do that. :-) I could probably
figure it out on my own, with the fine manual to help.
>> On MandrX 2006, copying a 50MB kernel-source RPM file from
>> one machine to itself uses much less CPU time with blowfish
>> than with "none":
>
>> option user CPU seconds
>> ----------- ----------------
>> -c blowfish 1.115
>> -c none 1.919
>> (blank) 2.006
>
>> It would appear '-c none' is not actually useful. I'll
>> still give blowfish a try.
>
> It says it would use defaults. Anyway, thx for taking the five
> minutes to actually try something out!
Actually, it only took two or three for that attempt, unless
we want to include the time to write it up and post here.
You should see the amount of time I spent trying to debug a
Firefox crash after the document window had gone solid lime
green. The version compiled with debug enabled and symbols
not stripped would crash before it even got started. After
several rounds of suggestions from the developers, we all
gave up.
Actually, at present, I have been using a short Java program
I wrote to do copying around the home LAN. If the blowfish
option doesn't work out, I'll just stick with that.
Again, thanks for pointing out the -c option to ssh and scp.
I try to read the fine manual, but my brain can only retain
a limited portion of what is in the manual.
Chris Davies
> why services such as rlogin, rsh, and rexec are dangerous
Bit Twister <BitTw...@mouse-potato.com> wrote:
> I also thought there could be a problem trusting the hostname of the
> client. :(
No, there's no major problem with that, unless you control the Reverse
DNS. The server does at least do a gethostbyaddr() call (i.e. rDNS or
/etc/hosts lookup) to determine the client's canonical hostname. Mind you,
that requires trusting rDNS.
The big problem lies with the username. The client tells the server
the username with which it wants to connect, and the server uses that
username along with the name is has determined from the rDNS lookup. If
that user has a corresponding entry in their .rhosts file on the server,
the server does not require entry of a password. Unfortunately, if the
password /is/ required, it's passed in clear text, so it's tribial to
snoop (even on a switched network).
Chris