Re: [SLUG] Perl/SSH Problem
1. That's what strong pass-phrases are used for - to limit the access to the private key. 2. You could say "sure - so you replace the password by a pass-phrase" but you'd still need the private key, which is never transferred over the net. 3. You can allow access for multiple keys into the same account - therefore you can trace which key was used to login and track it back to the origin and/or remove it if it was compromised (or do stuff like limit the commands a key authorizes, or pair keys with originating ssh clients). On the other hand you can't have multiple, traceable passwords to a UNIX account. With passwords, at least that isn't a problem (assuming you aren't a complete idiot and have the same password for everything). With passwords it's enough to know (or guess) a relatively short string in order to gain access. With keys protected by a pass-phrase you'll need a string AND the unencrypted content of a file which should never leave the local disk. Which is all fine and dandy, except the entire point of the original key argument was that the original poster wouldn't need a pass(word|phrase) and so could avoid his problem with the method SSH uses for prompts. Adam K -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On 04/11/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: I always thought the problem with keys and passwordless login was that you end up with cascading exploits. If I login from box A --> box B with keys, and someone hacks box A, then they automatically have access to box B, and C, and D and anything else I use keys on 1. That's what strong pass-phrases are used for - to limit the access to the private key. 2. You could say "sure - so you replace the password by a pass-phrase" but you'd still need the private key, which is never transferred over the net. 3. You can allow access for multiple keys into the same account - therefore you can trace which key was used to login and track it back to the origin and/or remove it if it was compromised (or do stuff like limit the commands a key authorizes, or pair keys with originating ssh clients). On the other hand you can't have multiple, traceable passwords to a UNIX account. With passwords, at least that isn't a problem (assuming you aren't a complete idiot and have the same password for everything). With passwords it's enough to know (or guess) a relatively short string in order to gain access. With keys protected by a pass-phrase you'll need a string AND the unencrypted content of a file which should never leave the local disk. --P -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
Passwdless login is infinitly better than passwd infact on my system: PermitRootLogin without-password with say 1024bit key and say 10^6 tries per second lets see ... 1024 log (2) / 10^6 is say 10^300 years to crack! Much better than any 10 char passwd. The weak link is storing YOUR private key. The rest is secure. Infact I'll TELL you my root passwd and you still can't get in I always thought the problem with keys and passwordless login was that you end up with cascading exploits. If I login from box A --> box B with keys, and someone hacks box A, then they automatically have access to box B, and C, and D and anything else I use keys on. If I can hack your box, I don't even need your root passwd, I'll just login directly to the box and it will let me straight in the front door. With passwords, at least that isn't a problem (assuming you aren't a complete idiot and have the same password for everything). Adam K -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On 11/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [..snip..] Passwdless login is infinitly better than passwd infact on my system: PermitRootLogin without-password with say 1024bit key and say 10^6 tries per second lets see ... 1024 log (2) / 10^6 is say 10^300 years to crack! Much better than any 10 char passwd. The weak link is storing YOUR private key. The rest is secure. Infact I'll TELL you my root passwd and you still can't get in I appreciate the suggestions, but I would still like to know why it doesn't work on my system. Putting aside that keys are better, passwordless logins are better, etc etc, I would like to know why it doesn't work on the 2 systems I've tried. Regards, Gonzalo -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On Friday 03 November 2006 20:14, [EMAIL PROTECTED] wrote: > > Why Choose not to use ssh keys. > > The default is to both allow passwords, and/or keys. > > I use SSH keys on many servers, but there are a bunch in this group > where the admins have *blocked* use of SSH keys and thus I would like > to have a system that works for ALL servers, and the only way I can > see that happening is by letting the script send the password when > prompted for it. > > > You don't need root access to create a passwordless login (providing the > > admin's haven't explicitly changed the default). > > I know, but imagine asking a server admin in a company where there are > lots of policies, bla bla, if I can have a passwordless login on an > account with special sudo privileges :) > > > Now the reason I suggested that is Net::SSH (Which cannot use passwords > > for login) uses Filehandles for reading and writing, so expect should > > "just work"(tm). Passwdless login is infinitly better than passwd infact on my system: PermitRootLogin without-password with say 1024bit key and say 10^6 tries per second lets see ... 1024 log (2) / 10^6 is say 10^300 years to crack! Much better than any 10 char passwd. The weak link is storing YOUR private key. The rest is secure. Infact I'll TELL you my root passwd and you still can't get in James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On 03/11/2006, at 4:15 PM, Gonzalo Servat wrote: ... Since Expect needs to either spawn a program or access a FH, Net::SSH::Perl no longer suited my needs. I started to look into spawning SSH from Net::Telnet, then using Expect on the Net::Telnet object. After looking at the man page for Net::Telnet, I found the SSH example. I copied and pasted exactly how it is and it was impossible to get it to work. It would connect to the remote server, but the program could never get the password prompt. It would see the permission denied messages, but NOT the password prompt. After some more reading tonight I discovered that, for security reasons, SSH writes to the controlling TTY, but with the Net::Telnet SSH example it should work as it is creating a PTY to do just that. Anyway, I did some more researching and found this excellent resource: http://www.modperl.com/perl_networking/sample/ch6.html Once again, I copied and pasted the code exactly as it is there, ran it and same problem. It can't see the password prompt that the SSH program is sending to the TTY! I'm pretty damn sure it is the fact that SSH is sending the password prompt to the TTY and Perl's PTY is not receiving it. Why? I don't know !! Could it be because the ssh password prompt is being written to standard error, rather than standard output? -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On 03/11/06, Gonzalo Servat <[EMAIL PROTECTED]> wrote: > You don't need root access to create a passwordless login (providing the > admin's haven't explicitly changed the default). I know, but imagine asking a server admin in a company where there are lots of policies, bla bla, if I can have a passwordless login on an account with special sudo privileges :) I usually think that people who suggest what I'm going to suggest are unrealistic puristic psychos, but still: QUIT. Using private/public keys instead of passwords should enhance security, not the other way around - if this account can do sudo then it is security's interest to force it to use keys and forbid use of passwords to login. If I'd find myself work for a place which can't comprehend this - I'd try to convince them or move on. Cheers, --P -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
On 11/3/06, Scott Ragen <[EMAIL PROTECTED]> wrote: Why Choose not to use ssh keys. The default is to both allow passwords, and/or keys. I use SSH keys on many servers, but there are a bunch in this group where the admins have *blocked* use of SSH keys and thus I would like to have a system that works for ALL servers, and the only way I can see that happening is by letting the script send the password when prompted for it. You don't need root access to create a passwordless login (providing the admin's haven't explicitly changed the default). I know, but imagine asking a server admin in a company where there are lots of policies, bla bla, if I can have a passwordless login on an account with special sudo privileges :) Now the reason I suggested that is Net::SSH (Which cannot use passwords for login) uses Filehandles for reading and writing, so expect should "just work"(tm). Well, Net::SSH might not be able to, but Net::Telnet should be able to by creating the pseudo controlling terminal as the manpage clearly states (with an example and all) but for some reason the PTY is not catching the password prompt. Thanks for your reply. Gonzalo -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Perl/SSH Problem
Why Choose not to use ssh keys. The default is to both allow passwords, and/or keys. You don't need root access to create a passwordless login (providing the admin's haven't explicitly changed the default). All you do on your mail machine is use ssh-keygen to generate the key you want, put the private key in ~/.ssh/ (the name depends on what type of key you made, man ssh-keygen for details. Then put the public keys on the ssh servers in ~/.ssh/authorized_keys That should basically be it. Now the reason I suggested that is Net::SSH (Which cannot use passwords for login) uses Filehandles for reading and writing, so expect should "just work"(tm). Cheers, Scott (apologies for the top post, I'm in a rush) [EMAIL PROTECTED] wrote on 03/11/2006 04:15:03 PM: > Hi All, > > Here's a tough one, at least it has been for me! As you can > see, I've almost given up. > > Here's the situation: I manage a lot of servers at my work. They are > all *NIX and so I've decided to write a bunch of Perl scripts to > handle a lot of the repetitive tasks I have to do on said servers. > > I started using Net::SSH::Perl and that worked great. Turns out some > servers only allow Telnet (no, I'm not root on the servers, only > manage accounts with limited sudo access otherwise I'd kick Telnet out > in favour of SSH) so I turned the structured programs into an OOP one > which worked well. Had SSH and Telnet now working. Here comes the hard > part. I decided it was time to manage some interactive programs on > said servers (say, passwd as an example) and so I started looking into > the Expect module for Perl. > > Since Expect needs to either spawn a program or access a FH, > Net::SSH::Perl no longer suited my needs. I started to look into > spawning SSH from Net::Telnet, then using Expect on the Net::Telnet > object. > After looking at the man page for Net::Telnet, I found the SSH > example. I copied and pasted exactly how it is and it was impossible > to get it to work. It would connect to the remote server, but the > program could never get the password prompt. It would see the > permission denied messages, but NOT the password prompt. After some > more reading tonight I discovered that, for security reasons, SSH > writes to the controlling TTY, but with the Net::Telnet SSH example it > should work as it is creating a PTY to do just that. > > Anyway, I did some more researching and found this excellent resource: > > http://www.modperl.com/perl_networking/sample/ch6.html > > Once again, I copied and pasted the code exactly as it is there, ran > it and same problem. It can't see the password prompt that the SSH > program is sending to the TTY! > > I'm pretty damn sure it is the fact that SSH is sending the password > prompt to the TTY and Perl's PTY is not receiving it. Why? I don't > know !! > > BTW, I'm not using SSH keys because of some limitations I have with a > bunch of servers. The safest bet is for the script to send the > password when it is prompted to do so, as this works on all the > servers whereas public keys don't (again, I'm not root on them, so I > can't fix it myself). Besides, it's far more entertaining finding the > solution to the problem I'm having :-) > > If anyone has any thoughts, ideas, etc... I'd really appreciate it. > > Regards, > Gonzalo > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Perl/SSH Problem
Hi All, Here's a tough one, at least it has been for me! As you can see, I've almost given up. Here's the situation: I manage a lot of servers at my work. They are all *NIX and so I've decided to write a bunch of Perl scripts to handle a lot of the repetitive tasks I have to do on said servers. I started using Net::SSH::Perl and that worked great. Turns out some servers only allow Telnet (no, I'm not root on the servers, only manage accounts with limited sudo access otherwise I'd kick Telnet out in favour of SSH) so I turned the structured programs into an OOP one which worked well. Had SSH and Telnet now working. Here comes the hard part. I decided it was time to manage some interactive programs on said servers (say, passwd as an example) and so I started looking into the Expect module for Perl. Since Expect needs to either spawn a program or access a FH, Net::SSH::Perl no longer suited my needs. I started to look into spawning SSH from Net::Telnet, then using Expect on the Net::Telnet object. After looking at the man page for Net::Telnet, I found the SSH example. I copied and pasted exactly how it is and it was impossible to get it to work. It would connect to the remote server, but the program could never get the password prompt. It would see the permission denied messages, but NOT the password prompt. After some more reading tonight I discovered that, for security reasons, SSH writes to the controlling TTY, but with the Net::Telnet SSH example it should work as it is creating a PTY to do just that. Anyway, I did some more researching and found this excellent resource: http://www.modperl.com/perl_networking/sample/ch6.html Once again, I copied and pasted the code exactly as it is there, ran it and same problem. It can't see the password prompt that the SSH program is sending to the TTY! I'm pretty damn sure it is the fact that SSH is sending the password prompt to the TTY and Perl's PTY is not receiving it. Why? I don't know !! BTW, I'm not using SSH keys because of some limitations I have with a bunch of servers. The safest bet is for the script to send the password when it is prompted to do so, as this works on all the servers whereas public keys don't (again, I'm not root on them, so I can't fix it myself). Besides, it's far more entertaining finding the solution to the problem I'm having :-) If anyone has any thoughts, ideas, etc... I'd really appreciate it. Regards, Gonzalo -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
