Jay,
You are right only the password authentication mode is supported. But I am not sure what I mentioned implied the use of authorized_hosts?
Once the session key is generated and encrypted by the client (using the RSA public key of the server), the server receive it and decrypt it using its private key. Then user authentication takes place.
Please let me know directly if the use of an authorized_hosts file would work better for your environment.
Hope this helps.
Nicolas.
-----Original Message----- From: Igor Schein [mailto:igor@txc.com] Sent: Tuesday, August 01, 2000 4:31 PM To: Philip, Nicolas Cc: toasters@mathworks.com Subject: Re: What about SSH
On Mon, Jul 31, 2000 at 04:44:18PM -0700, Philip, Nicolas wrote:
Jay,
Mike is right, SecureAdmin 1.0 is a product sold separately that installs a
SSH
server (Secure Shell protocol) on your filer running Data ONTAP 5.3.x. It supports SSH 1.x clients only.
It uses RSA for key echange (Host/Server key up to 1024 bits) and DES (56
bits)
or 3DES for data encryption. Filer commands and your login name + password are therefore encrypted when passed over the network to your remote filer.
Hmm, when I was testing SecureAdmin, I determined that it supports password-only authentication. I called support and they confirmed it. If you're saying it's not so, then I should be able to create authorized_hosts file on the filer, right? Where would it be located?
Thanks
Igor
On Tue, Aug 01, 2000 at 05:52:06PM -0700, Philip, Nicolas wrote:
Jay,
You are right only the password authentication mode is supported. But I am not sure what I mentioned implied the use of authorized_hosts?
Once the session key is generated and encrypted by the client (using the RSA public key of the server), the server receive it and decrypt it using its private key. Then user authentication takes place.
Please let me know directly if the use of an authorized_hosts file would work better for your environment.
It sure would, because it would allow a batch connection without having to type in a password from, very helpful for backup purposes. Of course it wouldn't be that important if ONTAP supported crontab ( a tiny hint here ).
-:)
Thanks
Igor
Of course it wouldn't be that important if ONTAP supported crontab ( a tiny hint here ).
I put in an RFE for this years ago when it became clear that the filer was going to start handling multiple configurabel timed events - snapshot creation, raid scrubbing, autosupport, etc. Clearly it would make more sense if all of these were collected in a single flat configuration file that admins could edit easily. You could even control the frequency of statd messages and self-initiate backups and other commands.
Bruce
You are right only the password authentication mode is supported. But I am not sure what I mentioned implied the use of authorized_hosts?
Once the session key is generated and encrypted by the client (using the RSA public key of the server), the server receive it and decrypt it using its private key. Then user authentication takes place.
Please let me know directly if the use of an authorized_hosts file would work better for your environment.
It sure would, because it would allow a batch connection without having to type in a password from, very helpful for backup purposes. Of course it wouldn't be that important if ONTAP supported crontab ( a tiny hint here ).
Agreed. Authorized_hosts would be really nice. We have account generation tied to our filer for doing quota resizes after generating new accounts. Our script can either telnet on, which means transferring the password in the clear and storing it in the script somwhere (albeit encrypted) or rsh'ing on. At least we can limit the machines that are allowed to rsh to the filer but we'd feel better with ssh and a keys.
Igor> It sure would, because it would allow a batch connection without Igor> having to type in a password from, very helpful for backup Igor> purposes. Of course it wouldn't be that important if ONTAP Igor> supported crontab ( a tiny hint here ).
cron + Expect on the Unix host would do the trick here too.
John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel@ascend.com - http://www.ascend.com
On Thu, Aug 03, 2000 at 05:53:27PM -0400, John Stoffel wrote:
Igor> It sure would, because it would allow a batch connection without Igor> having to type in a password from, very helpful for backup Igor> purposes. Of course it wouldn't be that important if ONTAP Igor> supported crontab ( a tiny hint here ).
cron + Expect on the Unix host would do the trick here too.
it would still require the cleartext password to be kep somewhere, which is against my religion. Nothing beats authorized_hosts setup as far as security and convenience.
Thanks
Igor
On Mon, Aug 07, 2000 at 10:34:58AM -0400, Igor Schein wrote:
On Thu, Aug 03, 2000 at 05:53:27PM -0400, John Stoffel wrote:
Igor> It sure would, because it would allow a batch connection without Igor> having to type in a password from, very helpful for backup Igor> purposes. Of course it wouldn't be that important if ONTAP Igor> supported crontab ( a tiny hint here ).
cron + Expect on the Unix host would do the trick here too.
it would still require the cleartext password to be kep somewhere, which is against my religion. Nothing beats authorized_hosts setup as far as security and convenience.
authorized_keys is also a clear-text password (for scripting you need to store the key without a passphrase or you need to store the passphrase), it is just not transmitted over the net in clear. The protection only helps against network sniffers but not against someone getting access to the scripts.
On Tue, 8 Aug 2000, Michael van Elst wrote:
The protection only helps against network sniffers but not against someone getting access to the scripts.
ssh-agent might help... keep an encrypted private key on disk, but have the unencrypted version in ssh-agent's memory space. You'd have to manually restart the authentication agent if it dies or if the server reboots though.