pix 5xx ssh server unexpectedly closed network connection from outside until touched from inside with PDM

Pix version 501  OS 6.5(3) PDM 3.0(4)

First off, I am not a pix GURU, but knowledgable.  Have have some pixii logging in via SSH on the outside interface.  We also have inside interface access to the pixii.  SSH outside interface is locked down to only specific from IPs.

On some of the pix (all are very close in versions, etc) (like 15%), SSH will not work on the outside interface utill the PDM is touched (just hit the pix with https) on the inside interface.  PUTTY and other SSH tools will not work on the outside interface until this is done.  The error message from PUTTY is "Server unexpcetedly clodes network connection".  The outside SSH then works for some time.

So far I have not been able to trace down a pattern to this failure.  As soon as the outside ssh failing pix is hit with an inside PDM request, it starts working.  

Is there some sort of lockout that is happening here?  If someone is attempting to break into the PIX using ssh, will ssh turn off on the outside interface?

Thanks in advance
ort11
LVL 1
ort11Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ort11Author Commented:
A bit more information.

Turns out if you "touch" the outside interface with the PDM (https) from a different from address, this also "allows" the outside interface that is not working to work.
Tim HolmanCommented:
Sounds peculiar, but I would suspect the TCP timeout for SSH and/or things like MTU may be causing problems.  
If you have a failing SSH client, can you run a www.ethereal.com trace on it to see which bit is failing?
Just in case you've run into a documented bug, also try the very latest version of PIX software.
Can you post up the PIX config too?
uberpoopCommented:
hmm. interesting... I bet the PDM (which uses HTTPS) automagically generates the keys etc required for encrypted communication... and I bet you didn't set that up manually.

That is my guess.

detailed steps on setting up ssh on pix are here... (includes generating the keys)

http://www.informit.com/articles/article.asp?p=25342
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

ort11Author Commented:
Thanks for the pointers.  I don't think that we can go to the next version for a bit, there are some differences and would have to test the configs, etc.  I will take other comments under advisement and get back, but it will take a week or two.

Thanks
ort11Author Commented:
Hi:  Thanks for the cleanup help, but I am still seeing this issue from time to time.  Some ssh outside access will work and some will not.

Thanks
 
JaedubCommented:
Actually the issue is the crypto RSA keys are not generated.  When you log in via PDM/ASDM that process gerenates a 768bit key and stores it in memory.  Then you can log in via SSH.  With out a RSA key you cannot initiate a SSH session b/c there is no key to negotiate with.

To FIX:
PREREQUITITES:
*DOMAIN NAME SET
*CORRECT TIME
*HOSTNAME SET

COMMANDS:
ca generate rsa key modulus 1024
ca save all
wr mem

You can pick a modulus from 512, 768, 1024, 2048.  The higher the modulus the longer it takes to gerenate the keys.

You should be fine now.
Tim HolmanCommented:
PDM does this for you.
JaedubCommented:
PDM does this for you as stated above.  Genreating a 768 bit key.  However, PDM does not issue the " ca save all " command.  If the box powers down or is reloaded, the key is gone from memory and a new key does not get generated until the next PDM session.

I knew this was so, but just to verify, I reproduced it 3 times in a lab in the last 15 minutes.

Ort11, you have your answer :-)

-J
uberpoopCommented:
ort 11- did you try the link I posted a month ago?... it details the process.
Tim HolmanCommented:
Jaedub - have you tried with PIX 7.0?  Or is this an undocumented  6.x feature?  ;)
JaedubCommented:
In 7.x SSL generates it's own certificate/key (1024 bit) dynamically unless a crypto trustpoint has one configured.  The dynamically generated key is not available to the SSH process. So the key must be generated manually.  "crypto key generate rsa" will gernerate a 1024 bit key.  If you then do a "write mem" the key will be saved (nice! no need for 'ca save all').

As far a PDM generating a key, this is documented in 1 sentence on page 4-10 and described on 4-11  of the 6.3x command reference.  It does not state the the key is not saved when the firewall is rebooted.
ort11Author Commented:
Ah, thanks all.  This now makes sense.  So if I get this right, for the 501's that I have in the field that are running 6.x, I simply need to do a

ca save all

which is not covered by the

write mem

and the SSH processes will no longer "not work" until touched by the PDM the remote 501's are reloaded, etc.

Thanks, will try and get back.
JaedubCommented:
Ort11,

Be sure to generate your keys first or log in to PDM first.  If you log in via PDM, you can perform the operation in PDM.  From the Menu select Tools > Command Line Interface...  In the Command box, type "ca save all" and click Send.

If you use the PDM to gerenate your key, remember that your key will only be 768 bit.  Decent strength, but not the maximum for the box; the two higher being 1024 and 2048. If you want to utilize a higher bit key yo uwill need to clear the auto generated 768 bit key first.  Do this by issuing the command "ca zeroize rsa" and then you may generate your higher bit key by issuing a "ca generate rsa key 1024" or "ca generate rsa key 2048" followed by a "ca save all".

to verify your work, you can look at your keys by issuing a "show ca mypubkey rsa"

THis will show you when the key was generated by the following output " Key pair was generated at: HH:MM:SS TZ MMM DD YYYY"
To see when that was on your machine, issue a "show clock"

-J

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ort11Author Commented:
Yes, this seems to be working, thanks again
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Security

From novice to tech pro — start learning today.