[Systers-dev] dev machine

[Kathy Richardson]

Svaksha,

I'm sorry you are having so many problems with this. 
why don't you just try moving your .ssh directory to .ssh2 and then 
login and install your key, And then try going back to the original .ssh 
and see if you can get that to work.

By weak ssh I just ment that it isn't using an installed key-pair.  It 
still does the same level of encryption, either way, except that it has 
to do more negotiation.

Time for bed here in CA.

-Kathy



स्वक्ष wrote:
> On Thu, Apr 29, 2010 at 04:13, Meryll Larkin <mll at alwanza.com> wrote:
>   
>> Hi Kathy,
>>
>> http://nic.phys.ethz.ch/news/1210776776/index_html
>>
>> It is my understanding that "weak ssh" means that the keys are comparitively
>> easy to guess, like weak passwords.  It is highly recommended that you don't
>> use "weak ssh".
>>     
>
> Maybe _that_ was why it was breaking my existing key and overwriting
> the known_hosts file. I had updated the ssh version as i have shell
> access on machines whose owners are picky about security *grin*
>
>
>   
>> I am not using "weak ssh".  I am using ssh version 2, and I can still login
>> to my personal dev machine using PuTTy.  I don't have an account on
>> dev.systers.org.
>>
>> ssh is something I DO know, very well.  Can I help you with this?
>>
>> I'm not sure what "shared keys" are - you shouldn't be using the same keys
>> for different accounts.
>>     
>
> Care to explain this? I am not sure how one user can generate multiple
> encrypted ssh keys for each machine they log into. Will your OS allow
> this? Ex.. you may log into a irc server, have commit rights
> elsewhere, pushing a merge on third server, etc ...all of which only
> need your public key for matching with the one stored on their end.
> By "shared keys", if you meant people using the same ssh key on
> different machines (at home and at work) then yes, that is poor
> security. However, it is possible that anyone having a backup of the
> ssh key on a pendrive or a portable disk can lose these backup devices
> and hence poor security too.  For this some servers use the IP address
> to limit ssh access <--i am not exactly sure how this works but i do
> know that i was barred access when i used my laptop from a different
> ip.
>
>
>   
>> I know how to set up security for ssh.  I know how
>> to set up (and explain in documentation) logins using public and private
>> keys (without passwords).
>>     
>
> True, ssh login with pub/private key with passwords (passphrase:)) is
> usually what is recommended. I am not sure how systers server is setup
> as I am unable to login.
>
>   
>> This discussion should really be on the list.
>> The machine being set up for this summer is dev.systers.org
>> Right now, it is set up so that folks with accounts on it can use
>> weak/negotiated ssh (I'm sure that isn't the right term). This means you
>> can login using putty and plain ssh.
>>     
>
> Is plain ssh==ssh sans encryption?
>
>
>   
>> Svaksha,
>>     
>
>   
>> I think the ssh weirdness is because it probably only likes having the
>> unknown host in one place, and once you have it there with a key (and a
>> shared key at that) things get weird. I think you should remove
>> dev.systers.org from your known hosts. I think it will then set up the
>> right thing when you do the say yes to the ssh w/o key pairs. I don't
>> know that if weird things will happen once you set up key pairs or not.
>>     
>
> Now I am confused by what you mean by shared key. Its hard to remove
> "dev.systers.org" or any host by hand as the ssh I use is encrypted.
> What I did was replace the file with a backup i maintain.
>
>
>   
>> We just missed each other on chat this morning.
>>     
>
> good morning :)
>
>