text:
Handbook of Genetic Counseling/Hemifacial Microsomia

Hemifacial Microsomia

(a.k.a. Goldenhar Syndrome, Oculoauriculovertebral Dysplasia, OAV Syndrome, Facio-Auriculo-Vertebral Spectrum, First & Second Branchial Arch Syndrome)

Introduction

 * Hemifacial Microsomia is a condition that affects the growth of the face. It is predominantly unilateral and involves the ear, mouth, and mandible. This disorder is extremely variable with many transitional forms affecting different systems (for example, Goldenhar Syndrome is used when there is ocular and vertebral involvement), which suggests that this disorder is a range along a continuous spectrum.

Genetic Etiology

 * HFM has an unknown etiology, but is usually sporadic. However, a few cases have had a positive family history suggesting autosomal dominant, autosomal recessive, or multifactorial. The estimated recurrence in first-degree relatives is about 2%, but the minor features of the disorder may be more commonly noted in relatives. The chances of having another child with Hemifacial Microsomia are less than 1%. An affected person has an approximately 3% chance of passing it on to their children.
 * HFM is thought to be caused by abnormal changes in blood vessels and the disruption of the blood supply during embryonic development (early vascular disruption) at about 30-45 days of gestation. This results in the destruction of differentiating tissue in the first and second branchial arches, from which certain ligaments and bones of the face, parts of the skull, and the middle ear develop.
 * No DNA abnormality has been identified. However, it has also been noted that certain teratogens (Thalidomide, Primidone, and Accutane) have produced birth defect patterns that are similar to the HFM spectrum. Also, a research study is being done to determine if there is a higher rate of Goldenhar Syndrome found in the children of Gulf War veterans.

Incidence

 * The frequency of occurrence is estimated to be 1 in 3000 to 1 in 5000, and there is a slight male predominance (3:2).

Clinical Features

 * Key features:
 * Facial - asymmetry (90%). . .right side predominance (62%)
 * hypoplasia of malar, maxillary, and/or mandibular region
 * macrostomia (lateral cleft-like extension of the corner of the mouth)
 * hypoplasia of the facial musculature
 * frontal bossing
 * Ear - microtia (malformation of the external ear from complete aplasia to a crumpled, distorted
 * pinna which is displaces anteriorly and inferiorly) (65%)
 * accessory preauricular tags and/or pits
 * middle ear anomaly with variable deafness
 * Eye - palpebral fissure is somewhat lowered on the affected side
 * Oral - diminished to absent parotid secretion
 * anomalies in function or structure of the tongue
 * malfunction of the soft palate
 * Associated findings:
 * prenatal growth deficiency, feeding difficulties
 * Vertebral - hemivertebrae or hypoplasia of vertebrae, usually cervical (40-60%)
 * Eye - epibulbar dermoid and/or lipodermoid
 * strabismus
 * unilateral coloboma of the superior lid
 * microphthalmia
 * Oral - cleft lip, cleft palate (7%)
 * Cardiac - various forms of heart disease (45-55%)
 * ventricular septal defect
 * patent ductus arteriosus
 * tetralogy of Fallot
 * coarctation of the descending aorta
 * Lung - pulmonary agenesis or hypoplasia of the lung
 * Renal - ectopic and/or fused kidneys
 * renal agenesis
 * double ureter
 * Nervous - mental retardation (10%)
 * occipital encephalocele
 * hydrocephalus
 * agensis of corpus callosum

Natural History

 * Hemifacial Microsomia is congenital and most of the physical characteristics are apparent at birth. However, the facial asymmetry may not become apparent until the child grows (usually by four years of age).

Testing

 * Prenatal diagnosis by ultrasound may be possible if there is severe hypoplasia of the mandible or severe abnormality of the auricle.

Management

 * Most of these patients have normal intelligence. Deafness should be tested for at an early age, and speech therapy is often necessary. Help may be required for feeding problems and encouraging weight gain in early infancy. Any congenital heart defects may require surgery. Plastic surgery may be used to reconstruct the ear, and bone distraction techniques are available to artificially lengthen the jaw bone to improve growth on the face. Children may also need ongoing orthodontic treatment.

Differential Diagnoses

 * Treacher-Collins Syndrome
 * CHARGE Association
 * VACTERL Association
 * Townes-Brocks Syndrome
 * Branchio-Oto-Renal (BOR) Syndrome
 * Chromosomal disorders (including Trisomy 9 Mosaicism, Trisomy 18, Ring 21 Chromosome, and Trisomy 22)
 * Teratogen exposure

Psychosocial Issues

 * Assess development.
 * Feeding problems?
 * Cleft lip or other surgical repair?
 * How are they dealing with the diagnosis?
 * Have they shared with the family? What were their reactions?
 * Have they taken the baby out of the house?
 * How do they feel about the public's response to the facial abnormalities?
 * Would they like to talk with other families going through the same thing?
 * How can we be helpful to them?

Resources

 * Hemifacial Microsomia/Goldenhar Syndrome Family Support Network
 * c/o Kayci Rush
 * 3619 Chicago Avenue
 * Minneapolis, MN 55407-2603
 * (612) 823-3529

 * Association of Birth Defect Children (ABDC)
 * 1-800-313-2232
 * http://www.birthdefects.org


text:
Handbook of Genetic Counseling/Opitz BBB - G Syndrome

Opitz BBB - G Syndrome

(Opitz Oculo-Geito-Laryngeal Syndrome, Hypertelorism-Hypospadias Syndrome, Opitz-Frias Syndrome)

Contracting

 * Acknowledge prior phone contact
 * What have you been told about why your were referred to genetics?
 * What questions or concerns would you like us to address today?
 * Set agenda for session

Genetic Etiology

 * Genetic heterogeneity
 * X-linked loci mapping to Xp22.3 and possibly Xq22
 * Only males affected
 * Sons of affected males can't be affected, daughters must be carriers
 * Women have 50% chance for each pregnancy to inherit the mutation
 * Sons of carrier women have 25% chance of being affected
 * Autosomal dominant inheritance at 22q11.2
 * Molecular genetics
 * Xp22.3 form is caused by mutation in MID1 gene
 * Gene product is midin
 * Midin is associated with microtubules throughout cell cycle
 * Xq22 form is caused by mutation in MID2 gene (recently identified)
 * Gene structure and protein product almost identical to MID1
 * Expressed in heart, but MID1 is not
 * Unsure of clinical implications at this point
 * Gene on chromosome 22 has not been determined yet
 * Spontaneous mutations are rare
 * Almost 100% penetrance

Incidence

 * Over 50 families reported in literature since 1965
 * Many families have not been reported

Clinical Features

 * Hypospadias (93%)
 * Hypertelorsim (91%)
 * Dysphagia (81%) - may be more common in X-linked form
 * Developmental delay (43%)
 * Kidney anomalies (42%)
 * Laryngotracheal Esophageal cleft (LTE) (38%)
 * Cleft lip and palate (32%)
 * Strabismus (28%)
 * Heart defects (27%)
 * Patent ductus arteriosus
 * Atrial septal defect
 * Conotruncal anomalies
 * Imperforate anus (21%) - may be more common in X-linked form
 * Undescended testes (20%)
 * Hypotonia - usually improves over time
 * Other characteristic facial findings:
 * Widow's peak hairline
 * Ear abnormalities (72%)
 * Low set
 * Prominent or rotated ears
 * Broad or flat nose
 * Small chin
 * Associated findings
 * Urinary tract problems
 * Large fontanels
 * Underdevelopment of corpus collasum
 * Lung abnormalities
 * Lipomas
 * Diastasis recti
 * Usually clinically indistinguishable regardless of etiology

Natural History

 * Great variation in range of severity
 * Males tend to be more severely affected than females
 * Women usually only mildly affected
 * Rarely symptoms are sever enough to cause death in infancy
 * Usually normal growth and normal life span

Testing

 * Usually clinical diagnosis is most reliable
 * Research testing for genes on X chromosome and chromosome 22
 * Mutations have been identified in some families with X-linked Opitz
 * If mutation is identified, other at risk relatives can be tested
 * Dr. Maximilian Muenke lab offers blood test for changes in MID1
 * Have found changes in 10 of 40 families studied
 * Working to find gene on Xq22
 * Prenatal diagnosis can be offered once change in MID1 identified
 * Polyhydramnios may be sign of affected fetus
 * Some features may be observed on level II ultrasound after 22 weeks

Surveillance, management, and treatment options

 * No "treatment" available
 * Surgical repair of heart defects, hypospadias, imperforate anus, LTE cleft, and some other findings when necessary
 * OT, PT, and speech therapy when necessary
 * Children with learning difficulties or mental retardation can obtain special services

Differential Diagnosis

 * FG syndrome
 * Brachio-skeletal-genital syndrome
 * Hypospadias and hypertelorism may be isolated or findings in many other syndromes

Psychosocial Issues

 * Guilt
 * Difficulty dealing with child with many medical issues
 * Fear of recurrence in future pregnancies
 * Financial burden
 * Changes in lifestyle, missed time at work to care for child with medical issues or mental retardation

Support/Resources

 * Pamphlet on Opitz Syndrome
 * Vanderbilit University Medical Center
 * DD-2205, MCN, Division of Medical Genetics
 * Nashville, TN 37232-2578
 * Available on line: www.opitznet.org/modopitz.html

 * Opitz Family Network
 * PO Box 515
 * Grand Lake Colorado 80447
 * Phone: 970-627-8935
 * Email: opitznet@mac.com
 * http://gle.egsd.k12.co.us/opitz/index.html

 * National Organization for Rare Disorders
 * Phone: 800-999-6673
 * http://www.nord-rdb.com/~orphan

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
User:JohnathanJStegeman

Johnathan Joseph Stegeman A.K.A. MidiMacMan

'Born August 7th, 1979 in Grand Junction, Colorado-USA'

'Composer/Artist/Musician--And here an active

'Reader, Writer, and Believer'

The value of the GNU Free Documentation License, and the people that choose to dontate a bit of their soul where they deem important, will soon amaze the world in ways we cannot yet imagine. The power in knowledge is set by the rule of its distribution, and through sharing and collaborative and encouragment of peer propogation, we will one day understand the value in fellow respect, and love, for others."

About Me My name is Johnathan J. Stegeman/MidiMacMan, and I am a composer, webmaster, photographer, graphic artist, and freelance writer from Denver, Colorado.

I am have been playing the piano since age five, and while I have had no classical or "formal" piano training, my self taught technique has been shaped mostly by ear, and my love for improvisational styles mixed in with fundamental theories about chord structures and harmonies.

I have faced great criticism for my approach to piano playing, and for particularly for the music I compose. Perhaps it is just rubbish, and will one day make a mockery out of my name-my Mother's name as I had no father growing up, and have grown up with the German half of my heritage knowning little of my my other roots, Mexican-or I may just be onto something that is ahead of the time. The later scenario at least maintains hope, and without that little bit of reassurance, I could not hardly keep writing music. Without writing music, I wouldn't feel but maybe a fraction of the person I am.

For you see music is my greatest passion, and therefore greatest source of sorrow, despair and frusration at times. It has occured to me that my songs may be loved by even just a few other souls, after I have passed through this human existence.......sadly this happens to many more artists that you may have ever imagined.

However, they never give up their motivation, as if forced by a etheral force to continue their artistic expression. Almost a curse it can feel at times, but I don't think that any artist, wether successfful, or not, would trade in this unseen force for anything in the world. I know for example: I would not trade my sense of hearing in for my sense of sight. But what a foolish bargain most people would agree............I cannot help the fact that my music is so much of me.

Only in the last two years, and after great rejection by the music world, despite rigorous study through high school, and three years of study at the University of Colorado at Denver, have Itaken up other artistic expressions. Web Design, Graphic Design, Freelance writing, and even advertising and product development are skills that I had no real training with, even through college. These skills have been fashioned through my own quest for knowledge, and are quite immature in development stages. Yet I am proud of where I have come, especially for the skills I have learned on my own.

What it has taught me, is that the world is anyones oyster........and you can harvest whatever riches you may admire...........with work and with the simplest desire.

Thanks for noticing perhaps something in my work. It all adds up to make all my effort have some final worth.

Sincerely, Johnathan J. Stegeman MidiMacMan. January, 2006. Age 26.

Always Yours, Johnathan J. Stegeman-MidiMacMan

title: User:JohnathanJStegeman


text:
Handbook of Genetic Counseling/Oral-Facial-Digital Syndrome - Type 1

Oral-Facial-Digital Syndrome - Type 1

Introduction and Contracting

 * What is your understanding about why Dr. wanted to follow up with ____in our genetics clinic?
 * What do you already know about OFD syndrome?
 * Do you have any questions you would like us to address today?
 * What is your main concern?
 * Outline the visit
 * I have a little family history info from when Dr. visited ____ in the hospital, but I will take a more detailed family history.
 * I will also obtain a little more information about _______'s medical history
 * Dr. will come in to examine _____ and he will probably want to take a look at some of the features that you (her mother) share with ________.
 * We will then discuss the diagnosis of OFD1 including the inheritance, and issues regarding the medical management.

Diagnosis

 * The diagnosis of OFD1 is established by clinical findings
 * Established at birth in some infants due to combination of oral, facial, and digital anomalies
 * In others it is suspected only after polycystic kidney disease is identified (usually in later childhood or adulthood)
 * In some it is only suggested after a woman has an affected child.

Oral

 * tongue is lobed (bifid or trifid)
 * tongue nodules (usually hamartomas or lipomas) occur in at least a third of those with OFD1
 * ankyloglossia is common (partial or complete fusion of the tongue to the bottom of the mouth) attributable to a short lingual frenulum
 * Cleft hard or soft palate, submucous cleft palate, or highly arched palate occur in over half of patients
 * Trifurcation of the soft palate has been reported
 * Alveolar clefts and accessory gingival frenulae are common (these fibrous bands are hyperplastic frenulae extending from the buccal mucous membrane to the alveolar ridge, resulting in notching of the alveolar ridges)
 * Dental abnormalities include missing teeth (most common), extra teeth, enamel dysplasia, and malocclusion

Facial

 * Ocular hypertelorism or telecanthus occurs in at least 33%
 * Hypoplasia of the alae nasi, median cleft lip or pseudocleft upper lip, and micrognathia are common (exact frequencies unknown )

Digital

 * brachydactyly (short digits), syndactyly (fused digits) of varying degrees, and clinodactyly (inward curvature) of the fifth finger are all common
 * other fingers, particularly the third (i.e., middle finger) may show variable radial or ulnar deviation
 * duplicated hallux (great toe) occurs in less than half of patients and is usually unilateral
 * preaxial or postaxial polydactyly of the hands (1-2% of patients)
 * Radiographs of the hands often demonstrate fine reticular radiolucencies, described as irregular mineralization of the bone, with or without spicule formation of the phalanges

Brain

 * Structural brain abnormalities occur in 10-15% (may be an underestimate)
 * most common include
 * intracerebral cysts
 * agenesis of the corpus callosum
 * cerebellar agenesis with or without Dandy-Walker malformation
 * Other reported anomalies have each been described in a few patients
 * type 2 porencephaly (schizencephalic porencephaly)
 * pachygyria (abnormally large convolutions of cerebral cortex) and heterotopias (displacement of gray matter typically into the white matter)
 * hydrocephalus
 * cerebral or cerebellar atrophy

Kidney

 * polycystic kidney disease (unknown frequency) fewer than 50%
 * age of onset most often adulthood (but have been described in children)

Intellect

 * As many as half of the individuals with OFD1 have some degree of mental retardation, which is usually mild
 * Depends in part on brain abnormalities, but not always consistent
 * Severe mental retardation in the absence of brain malformations appears to be rare

Other

 * Rare manifestations include choanal atresia, tibial pseudarthrosis, and berry aneurysms
 * Hair is often described as dry, coarse, and brittle
 * Alopecia (absence of hair), usually partial, is an occasional finding
 * Milia, small keratinizing cysts, occur in at least 10% (but likely more) occur most often on the scalp, ear pinnae, face, and dorsa of the hands
 * milia are usually present in infancy and then resolve, but can then leave pitting scars

Incidence

 * Estimates range from 1/50,000 to 1/250,000

Inheritance

 * OFD1 is inherited in an X-linked dominant manner
 * Almost all affected individuals are female
 * reports of males with OFD1
 * some males are described as malformed fetuses born to women with OFD1
 * in most cases the diagnosis is uncertain because the mother is unaffected
 * Approximately 75% of cases are sporadic (should examine mother and take family history to determine this)

Caveats of inheritance

 * One family with a peculiar inheritance pattern has been described. In this pedigree, a woman with OFDI had four unaffected sons, three of whom then had daughters all affected with OFDI
 * Often, mildly affected female relatives are diagnosed only after the identification of a severely affected individual

Recurrance risks

 * If there is no family history of OFD1, the risk that an unaffected mother of an affected female will have another female with OFD1 is less than 1% due to the possibility of
 * 1) a new mutation in a second child
 * 2) germline mosaicism in a parent (more likely than new mutation)
 * Germline mosaicism is when a person unaffected by OFD1 has multiple copies of the OFD1 mutation in their gametes
 * Theoretically, germline mosaicism can occur in either parent of a female with OFD1
 * At conception, the risk to the offspring of females with OFD1 of inheriting the mutant OFD1 is 50% (most male conceptuses with the mutant OFD1 allele miscarry)
 * At delivery the expected sex ratio of offspring is: 33% unaffected females; 33% affected females; 33% unaffected males

Recurrance is a misspelling. This should instead be 'Recurrence'

Genetic Testing

 * OFD1 is the only gene currently known to be associated with oral-facial-digital syndrome type I
 * chromosomal locus Xp22.3-p22.2
 * Molecular genetic testing of the OFD1 gene is available on a research basis only
 * Tested in a limited number of patients
 * A variety of mutations have been identified, the majority result in premature protein truncation
 * Detection rate unknown

Molecular genetics

 * Normal allelic variants:
 * OFD1 has 23 exons
 * OFD1 is on the portion of the X chromosome that escapes inactivation
 * OFD1 was expressed in all adult tissues that were examined. However, during early development, expression is exclusively in the genital ridges, soon followed by expression in craniofacial structures and nervous system
 * Homologous genes include Cyorf1 (Y chromosomes) and C5orf1 (chromosome 5)
 * Pathologic allelic variants:
 * Exonic and intronic mutations have both been described
 * Mutations in exons include single base pair changes, frameshifts, and deletions
 * These changes have occurred to date in exons 3, 11, 13, and 16 only
 * Abnormal splicing has also been reported in introns 4 and 5

Normal gene product

 * The protein OFD1 occurs in two forms, Cxorf5-1 and Cxorf5-2, which are differentiated by the use of an alternative splice site
 * Cxorf5-1 is a 1011 amino acid protein, whereas Cxorf5-2 is a 367 amino acid protein
 * The two proteins share the first 351 amino acids; Cxorf5-2 then has a C-terminal region of 16 amino acids
 * The function of the protein is unknown, but thought to be related to a protein-protein interaction mechanism during development

Abnormal gene product

 * Most of the mutations lead to the premature truncation of the protein and are therefore thought to result in a loss of function
 * Since this gene is on the portion of the X chromosome that escapes inactivation, the truncated protein may interact with the wildtype product to produce a dominant-negative effect
 * No genotype-phenotype correlation exists to date.

Prenatal testing

 * Prenatal testing using molecular genetic techniques is not clinically available
 * Prenatal ultrasound examination may detect structural brain malformations and duplicated hallux

Differential diagnosis
(includes the other oral-facial-digital syndromes and disorders including cystic renal disease)
 * OFD II (Mohr syndrome)
 * Autosomal recessive
 * primarily distinguished by polydactyly (bilateral postaxial polydactyly of hands, bilateral polysyndactly of feet)
 * other manifestations include broad (sometimes bifid) nasal tip
 * midline partial cleft of lip
 * these individuals do not have milia or polycystic kidney disease
 * OFD III (Sugarman syndrome)
 * Autosomal recessive
 * characterized by see-saw winking and polydactyly only postaxial
 * myoclonic jerks (also occur)
 * bulbous nose (may also occur)
 * apparently low set ears (also occur)
 * OFD IV (Buru-Baraister syndrome)
 * Autosomal recessive
 * tibial involvement (short tibia) and pre and or postaxial polydactyly (primary manifestations)
 * Other findings include pectus excavatum and short stature
 * OFD V (Thurston syndrome)
 * Autosomal recessive
 * includes polydactyly and median cleft lip only
 * Only one affected individual has had hyperplastic frenula
 * OFD VI (Varadi-Papp syndrome)
 * distinguished by polydactyly (particularly central) and cerebellar malformations
 * Renal agenesis and dysplasia have been described
 * OFD VII (Whelan syndrome)
 * includes unilateral cleft lip and hydronephrosis
 * only been described in one mother-daughter pair
 * congenital hydronephrosis, coarse hair, facial asymmetry, facial weakness, preauricular tags
 * Inheritance either autosomal or X-linked dominant
 * may be allelic to OFD1 if X-linked dominant
 * OFD VIII
 * apparently inherited as an X-linked recessive trait
 * combination of polydactyly, tibial and radial defects, and epiglottal abnormalities
 * pre and postaxial polydactyly of hans and bilateral duplication of halluces, short stature, bypoplasia of the epiglottis, absent/abnormal central incisors, broad/bifid nasal tip
 * may be allelic to OFD1
 * OFD IX
 * includes retinal abnormalities and nonmedian cleft lip
 * reported in three males
 * Autosomal dominant polycystic kidney disease (ADPKD)
 * In ADPKD cysts develop from tubules, whereas in OFD1 cysts develop from both tubules and glomeruli
 * however, imaging studies cannot always distinguish the renal cystic disease of OFD1 from that of ADPKD and other cystic renal disorders
 * cysts are said to be smaller and more uniform in size in OFD1 than in ADPKD, and the kidneys are not as enlarged or deformed in OFD1
 * hepatic cysts and berry aneurysms have been observed in OFD1
 * Other distinguishing features are mode of inheritance and the lack of oral, facial, digital, or brain abnormalities in ADPKD
 * Meckel-Gruber syndrome
 * autosomal recessive condition characterized by the combination of encephalocele, polydactyly, and polycystic kidney disease
 * Other common findings include microphthalmia (small eyes) or anophthalmia (no eyes), cleft lip/palate, hepatic fibrosis and cysts, and congenital cardiac defects

Health concerns and management

 * Treatment for OFD1 is supportive
 * Removal of accessory teeth; orthodontia for malocclusion; and cosmetic or reconstructive surgery for clefts of the lip and/or palate, tongue nodules, accessory frenula, and syndactyly
 * Hearing loss from recurrent otitis media, usually associated with cleft palate, has been reported
 * End stage renal disease (ESRD) has been reported in affected girls and women ranging in age from 11 years to age 70 years
 * Management of renal disease may require hemodialysis or peritoneal dialysis and renal transplantation.
 * Recently it has been emphasized that the risk for significant renal disease may be greater than previously reported
 * Liver and pancreatic cysts may be observed
 * Laboratory investigations such as creatinine levels and blood pressure determination to monitor renal function should be done
 * if appropriate, imaging studies of the kidneys, liver, and pancreas should be performed

Patient Resources
(I found no patient literature that I felt was good or appropriate)
 * http://www.netnet.net/mums/ -- Website where parents are matched up according to the condition that their child has. There are currently at least 4 people registered with OFD syndrome type I and 15 just listed under OFD syndrome.
 * American Cleft Palate-Craniofacial Association
 * 104 South Estes Drive, Suite 204
 * Chapel Hill, NC 27514
 * Phone: 919-933-9044
 * Fax: 919-933-9604
 * Email: cleftline@aol.com
 * www.cleftline.org

 * National Kidney Foundation
 * 30 East 33rd Street, Suite 1100
 * New York, NY 10016
 * Phone: 800-622-9010 or 212-889-2210
 * Fax: 212-689-9261
 * Email: Info@kidney.org
 * www.kidney.org


text:
Engineering Acoustics/Car Mufflers:Animation

The following picture shows how the pressure varies along the tube. The bleu color represents the low pressure and the color red the high pressure. X represents the place where the section of the tube changes.

Matlab code

Original data were picked from the course material from the Acoustical Engineering course from the Purdue University with the kind authorization of Prof. L. Mongeau.

Back to Muffler Page


text:
Engineering Acoustics/Car Mufflers:Animation:code

% Duct with enlargement - last modified 11/03/99

% Reproduit avec l'aimable permission de Prof. L. Mongeau

clear all;

clc;

close all;

Nsteps=30;

f=86*2;	% frequency

rho=1.15;

c=344.;

rhoc=rho*c;

l=1;	%length of duct

a1=0.0762/2;

S1=pi*a1^2;

a2=0.1524/2;

S2=pi*a2^2;

m=S2/S1;

w=2*pi*f;

k=w/c;

t=linspace(2*pi/Nsteps/w,2*pi/w,Nsteps);	%Nsteps time steps per period

alpha1=2.93e-5/a1.*sqrt(f);

alpha2=2.93e-5/a2.*sqrt(f);

khat=k-i*alpha1;

kl=khat*l;

U0=0.01;

R=(1-m)/(m+1);

A=rho*c*U0./(exp(i*kl)-R*exp(-i*kl));

B=R*A;

C=A+B;

x=linspace(0,2,100);	% computational domain

y=linspace(-0.2,0.2,32);

for m=1:50

for k=8:24

pt(k,m)=A*exp(i*khat*(l-x(m)))-B*exp(-i*khat*(l-x(m)));

end

end

for m=51:100

for k=1:32

pt(k,m)=C*exp(i*khat*(l-x(m)));

end

end

pmag=abs(pt); pphase=angle(pt);

clim=max(max(pmag));

V=[-clim clim];	% sets color scheme

pt=pmag.*exp(i*pphase);	% red: maximum positive

% blue: minimum negative pressure

figure(1)

pt2=real(pt);

H=pcolor(x,y,pt2);

axis equal % to eliminate distortion

axis([0 2 -.2 .2])

M=moviein(Nsteps);	% for Matlab movie animation

for k=1:Nsteps

pt2=real(pt*exp(i*w*t(k)));

H=pcolor(x,y,pt2);

axis equal

xlabel('x');

ylabel('y');

title('pressure')

shading interp;

caxis(V);

axis([0 2 -.2 .2])

M(:,k)=getframe;

% to store the images for web posting (bitmaps)

% filnme=strcat('spher',int2str(k));

% eval(['print -dbitmap ' filnme ' -f']);

end

movie(M,20)

Back to Car Mufflers


text:
User:RedDragonAkai~enwikibooks/sandbox

Impulse Function

dolorum ipsut latin latin greeky talksisum vini vidi vici salve semper ubi sub ubi et salve discipuli et discipulae

\int _{-\infty} ^{t} u(s) \, ds = \left\{ \begin{array}{l l} 0, & \quad \mbox{if $t<0$}\\ \int _0 ^t \, ds & \quad \mbox{if $t \geq 0$}\\ \end{array} \right\} = t u(t)math>

title: User:RedDragonAkai~enwikibooks/sandbox


text:
Talk:TI-Basic Z80 Programming/List of Commands

Module size
I must suggest a change in the plan for the list of instructions. Having a whole module for each one does not seem appropriate to me. I like the content so far, and there is some more detail and an example or two that could be added. But even with that, a lot of them would consist only of two or three paragraphs - - a little small for a module.

Having a module for the CTL instructions and having the link to IF be TI-Basic:Instructions:CTL makes more sense (especially for those that are really small like Stop.) --MathMan64 05:29, 8 December 2005 (UTC)


text:
Drugs:Fact and Fiction/Marijuana

Cannabis is a leafy plant which grows wild in many of the tropic and temperate areas of the world. It is cultivated both indoors and out for the production of its flowering tops. The most commonly used form of cannabis are the leaves and flowering tops (buds) which may be either smoked or eaten; It also comes in a more concentrated resinous form called hashish, and as a sticky black liquid called hash oil. There are three distinct genera of cannabis: Cannabis sativa, Cannabis indica, and Cannabis ruderalis. Most recreationally used cannabis is the result of interbreeding between these three types. The term 'hemp' is generally used to describe low-thc varieties of cannabis which are grown for industrial uses.

Effects on the Brain
Scientists have learned a great deal about how THC acts in the brain to produce its many effects. When someone smokes marijuana, THC rapidly passes from the lungs into the bloodstream, which carries the chemical to the brain and other organs throughout the body.

THC acts upon specific sites in the brain, called cannabinoid receptors, kicking off a series of cellular reactions that ultimately lead to the “high” that users experience when they smoke marijuana. Some brain areas have many cannabinoid receptors; others have few or none. The highest density of cannabinoid receptors are found in parts of the brain that influence pleasure, memory, thoughts, concentration, sensory and time perception, and coordinated movement.

Not surprisingly, marijuana intoxication can cause distorted perceptions, impaired coordination, difficulty in thinking and problem solving, and problems with learning and memory. Research has shown that marijuana’s adverse impact on learning and memory can last for days or weeks after the acute effects of the drug wear off. As a result, someone who smokes marijuana every day may be functioning at a suboptimal intellectual level all of the time.

Research on the long-term effects of marijuana abuse indicates some changes in the brain similar to those seen after long-term abuse of other major drugs. For example, cannabinoid withdrawal in chronically exposed animals leads to an increase in the activation of the stress-response system and changes in the activity of nerve cells containing dopamine. Dopamine neurons are involved in the regulation of motivation and reward, and are directly or indirectly affected by all drugs of abuse.

Effects on the Lungs
Numerous studies have shown marijuana smoke to contain carcinogens and to be an irritant to the lungs. In fact, marijuana smoke contains 50–70 percent more carcinogenic hydrocarbons than does tobacco smoke. Marijuana users usually inhale more deeply and hold their breath longer than tobacco smokers do, which further increase the lungs’ exposure to carcinogenic smoke. Marijuana smokers show dysregulated growth of epithelial cells in their lung tissue, which could lead to cancer; however, a recent case-controlled study found no positive associations between marijuana use and lung, upper respiratory, or upper digestive tract cancers. Thus, the link between marijuana smoking and these cancers remains unsubstantiated at this time.

Nonetheless, marijuana smokers can have many of the same respiratory problems as tobacco smokers, such as daily cough and phlegm production, more frequent acute chest illness, and a heightened risk of lung infections. A study of 450 individuals found that people who smoke marijuana frequently but do not smoke tobacco have more health problems and miss more days of work than nonsmokers. Many of the extra sick days among the marijuana smokers in the study were for respiratory illnesses.

Effects on the Heart
Marijuana increases heart rate by 20–100 percent shortly after smoking; this effect can last up to 3 hours. In one study, it was estimated that marijuana users have a 4.8-fold increase in the risk of heart attack in the first hour after smoking the drug. This may be due to the increased heart rate as well as effects of marijuana on heart rhythms, causing palpitations and arrhythmias. This risk may be greater in aging populations or those with cardiac vulnerabilities.

Effects on Mental Health
A number of studies have shown an association between chronic marijuana use and increased rates of anxiety, depression, suicidal ideation, and schizophrenia. Some of these studies have shown age at first use to be a factor, where early use is a marker of vulnerability to later problems. However, at this time, it is not clear whether marijuana use causes mental problems, exacerbates them, or is used in attempt to self-medicate symptoms already in existence. Chronic marijuana use, especially in a very young person, may also be a marker of risk for mental illnesses, including addiction, stemming from genetic or environmental vulnerabilities, such as early exposure to stress or violence. At the present time, the strongest evidence links marijuana use and schizophrenia and/or related disorders. High doses of marijuana can produce an acute psychotic reaction; in addition, use of the drug may trigger the onset or relapse of schizophrenia in vulnerable individuals.

Other Effects
Other effects include dry mouth ("pasties" or "cotton mouth"), increased appetite ("munchies"), and "red-eye". The first is a common effect from smoking anything. THC activates parts of the brain (Cannabinoid receptors) which are linked to appetite. (It is believed that cannabinoid receptors are activated after birth to make an infant hungry until they can learn the daily routine of eating). THC also causes dilation of blood vessels which can lead to the "red-eye". THC can also lower intra-ocular (eye) pressure making it useful as a treatment for glaucoma.

Cannabis has an anti-nauseante property. However, like most antiemetics, this effect is seemingly reversed with higher doses.

Addictive Potential
Long-term marijuana abuse can lead to addiction; that is, compulsive drug seeking and abuse despite its known harmful effects upon social functioning in the context of family, school, work, and recreational activities. Long-term marijuana abusers trying to quit report irritability, sleeplessness, decreased appetite, anxiety, and drug craving, all of which make it difficult to quit. These withdrawal symptoms begin within about 1 day following abstinence, peak at 2–3 days, and subside within 1 or 2 weeks following drug cessation.

Use and Appeal
Cannabis is one of the most commonly abused drugs. Effects include relaxation, fatigue, increased emotional reaction (e.g., laughter), and muscle relaxation.

The effects typically subside between 1 and 4 hours after smoking, depending on the users body build.

Effects on Daily Life
Research clearly demonstrates that marijuana has the potential to cause problems in daily life or make a person’s existing problems worse. In one study, heavy marijuana abusers reported that the drug impaired several important measures of life achievement including physical and mental health, cognitive abilities, social life, and career status. Several studies associate workers’ marijuana smoking with increased absences, tardiness, accidents, workers’ compensation claims, and job turnover.

Non-Recreational Usage
Hemp can be used to make paper, textiles (clothing, furniture upholstery, sails, etc.), fuel, and food. It can be grown rather easily and harvested several times annually.

title: Drugs:Fact and Fiction/Marijuana


text:
Drugs:Fact and Fiction/LD50

The LD/50 of any substance is the lethal dose amount - typically given in a milligrams of the substance per kilogram of the users weight (mg/Kg) - needed to cause death to 50% of users.

This of course is never tested on humans. Instead a drug is administered intravenously to rats.

The number is not very reliable for two major reasons: First of all, there is quite a difference between humans and rats. Humans have a completely different metabolism compared to our furry friends. This can either mean it takes more or less of a substance to reach LD/50, depending on the drug.

Secondly, many drugs are ingested orally. When something is absorbed by the GI track, it makes a pass through the liver. The liver breaks down a certain amount of the substance, usually into inactive chemicals (Although sometimes the liver breaks down an inactive chemical into an active one, such as with Codeine.

Wherever possible, this book includes the known human overdose threshold (Which is often a good deal below the LD/50), and/or a safe dosage range to stay clear of any dangers.

title: Drugs:Fact and Fiction/LD50


text:
User talk:Milleram

Copyright problem with Image:Roomacoustics1.jpg
--Derbeth talk 06:54, 8 December 2005 (UTC)

title: User talk:Milleram


text:
Cookbook:Pierogi I

| Cuisine of Poland

Pierogi are Polish dumplings that are typically filled with potatoes, cheese, meat, sauerkraut and mushrooms, or wild fruits (strawberries, blueberries, etc.).

Ingredients

 * 1 tbsp salt
 * ½ cup cold water
 * 1–2 large eggs
 * 3½ cups all-purpose flour, plus extra for rolling dough
 * ~1 cup water
 * 1½ tbsp unsalted butter, melted
 * 1 recipe sauerkraut filling or cheese filling

Dough

 * 1) Place flour in a large bowl.
 * 2) In a measuring cup, combine the salt, eggs, and the ½ cup cold water, and beat well with a fork. Add those ingredients to flour and mix with your hands until blended.
 * 3) Slowly mix in the remaining water (you do not have to add the entire cup, just keep adding until the dough feels wet).
 * 4) Add the butter and knead until there are no lumps and it feels very smooth. This should take 15 minutes.
 * 5) Cover and refrigerate the dough for at least 1 hour, but for best results let it sit in the refrigerator for at least 24 hours.

Assembly

 * 1) Divide the dough into thirds and roll out each on a lightly floured surface until the dough is approximately ⅛ inch thick.
 * 2) With a cup or glass, cut as many circles as possible out of the dough, but do not lift them off the work surface.
 * 3) Carefully lift each circle of dough from the table (a spatula helps) and put between 1 tsp and 1 tbsp of filling in its center. The amount varies depending on the size of the glass that was used to cut the dough.
 * 4) For each circle, fold dough over to form a half-moon shape, and pinch edges closed, making sure there are no air pockets.
 * 5) Repeat for the remaining dough.

Boiling

 * 1) Place no more than ⅓ of the pierogi at a time in boiling salted water for 5–10 minutes.
 * 2) Drain in colander and lightly rinse with cold water—this will prevent them from sticking together.
 * 3) Serve immediately or fry in butter.

Notes, tips, and variations

 * These will freeze well for up to 6 weeks. Prior to boiling them, place each dumplings on a sheet of parchment paper or a floured sheet of wax paper, being careful not to have them touching. Stack sheets on top of each other and place in an airtight freezer bag.
 * A standard recipe for mashed potatoes can also be used as filling.

Livre de cuisine/Pierogi Libro di cucina/Ricette/Pierogi Kokboken/Recept/Piroger

title: Cookbook:Pierogi I


text:
Cookbook:Cheese Pierogi Filling

 * Poland

Ingredients

 * 8 oz farmer's cheese (a soft, NOT a hard cheese)
 * 4 oz cream cheese
 * 1 egg
 * 2 tbsp flour

Procedure

 * 1) Mash together all of the ingredients until well mixed.

Notes, tips, and variations

 * Farmer's cheese is similar to a dry-curd cottage cheese and is unavailable outside predominately Eastern European and Jewish areas. Dry-curd cottage cheese is a sub-par substitution, and must be drained of all excess liquid if it is to be used.
 * If the farmer's cheese is unsalted, add 1 tsp salt.

title: Cookbook:Cheese Pierogi Filling


text:
Cookbook:Sauerkraut Pierogi Filling

| Poland

Ingredients

 * 1 large can (~28 oz) sauerkraut
 * 1 medium onion, diced
 * 1 stick (8 tbsp) butter
 * Salt
 * Black pepper

Procedure

 * 1) Place sauerkraut and liquid in a pot filled with just enough water to cover the sauerkraut. Bring to a boil, then remove from stove and transfer to a colander.
 * 2) Drain and rinse the sauerkraut well with cold water to prevent further cooking. With your hands, squeeze as much liquid from the kraut as you can to prevent the filling from being too soggy.
 * 3) Place the sauerkraut on a large cutting board and chop fine with a large, flat-bladed knife.
 * 4) Fry the onion until it is translucent, then add the drained sauerkraut. Season with salt and pepper to taste.
 * 5) Simmer for 15 minutes and let it cool before using. For best results, refrigerate a few hours before using to fill pierogi.

Notes, tips, and variations

 * The sauerkraut boiling step may be omitted if you like really strong sauerkraut.

title: Cookbook:Sauerkraut Pierogi Filling


text:
Online OsiriX Documentation/SourceForge BugReporter

One of the better ways to file a bug report is via the SourceForge Bug Reporter. SourceForge is the World's largest OpenSource software repository and contains the source code for OsiriX.

You can access it via http://sourceforge.net/projects/osirix/ which should take you to a screen looking similar to this:

Clicking on the Bugs label will take you to a summary of all currently open bugs that have been filed via this system.

Click on the Submit New label to create a new bug.

Add a description.

Optionally upload a file, such as a CrashReporter log.

Click the Submit label and your newly reported bug will be added to the list.

One of the developers will pick up responsibility for this bug in due course. Once resolved the bug will be closed, perhaps with a message detailing the fix.


text:
User:Swapnil durgade

= SSH Without Password In Linux=

=Crontab Format=

=Masquerade domain in postfix - Swapnil=

=LDAP authentication in Linux=

=NX Terminal Server on Fedora Core 3=

=Cryptography/Notes-Under Construction=

=Perl Notes-Under Costruction=

=Scheduling Jobs in Linux=

=Regular Expressions Notes=

=Service management under Linux=

=Bind Notes=

=Oracle9i RAC on Fedora Core 1=

title: User:Swapnil durgade


text:
OpenSSH/Cookbook/Public Key Authentication

Authentication keys can improve efficiency, if done properly. As a bonus advantage, the passphrase and private key never leave the client. Key-based authentication is generally recommended for outward facing systems so that password authentication can be turned off.

Key-based authentication
OpenSSH can use public key cryptography for authentication. In public key cryptography, encryption and decryption are asymmetric. The keys are used in pairs, a public key to encrypt and a private key to decrypt. The ssh-keygen(1) utility can make RSA, Ed25519, ECDSA, Ed25519-SK, or ECDSA-SK keys for authenticating. Even though DSA keys can still be made, being exactly 1024 bits in size, they are no longer recommended and should be avoided. RSA keys are allowed to vary from 1024 bits on up. The default is now 3072. However, there is only limited benefit after 2048 bits and that makes elliptic curve algorithms preferable. ECDSA can be 256, 384 or 521 bits in size. Ed25519, Ed25519-SK, and ECDSA-SK keys each have a fixed length of 256 bits. Shorter keys are faster, but less secure. Longer keys are much slower to work with but provide better protection, up to a point.

Keys can be named to help remember what they are for. Because the key files can be named anything it is possible to have many keys each named for different services or tasks. The comment field at the end of the public key can also be useful in helping to keep the keys sorted, if you have many of them or use them infrequently.

The process of key-based authentication uses these keys to make a couple of exchanges using the keys to encrypt and decrypt some short message. At the start, a copy of the client's public key is stored on the server and the client's private key is on the client, both stay where they are. The private key never leaves the client. As the client first contacts the server, the server responds by using the client's public key to encrypt a random number and return that encrypted random number as a challenge to the client. The client responds to the challenge by using the matching private key to decrypt the message and extract the random number. The client then makes an MD5 hash of the session ID along with the random number from the challenge and returns that hash to the server. The server then makes its own hash of the session ID and the random number and compares that to the hash returned by the client. If there is a match, the login is allowed. If there is not a match, then the next of any public keys on the server registered as belonging to the same account is tried until either a match is found or all the keys have been tried or the maximum number of failures has been reached.

When an agent is used on the client side to manage authentication, the process is similar. The difference is that ssh(1) passes the challenge off to the agent which then calculates the response and passes it back to ssh(1) which then passes the agent's response back to the server.

Basics of Public Key Authentication
A matching pair of keys is needed for public key authentication and ssh-keygen(1) is used to make the key pair. Out of that pair the public key must be properly stored on the remote host. There on the server public key is added to the designated authorized_keys file for that remote user account. The private key stays stored safely on the client. Once the keys have been prepared they can be used again and again.

There are four steps in preparation for key-based authentication:

1) Prepare the directories where the keys will stay. If either the authorized_keys file or .ssh directory do not exist on either the remote machine or the .ssh directory on the remote machine, create them and set the permissions correctly.  On the client only a directory is needed, but it should not be writable by any account except its owner:

On the remote machine, the .ssh directory is needed as is a special file to store the public keys, the default is authorized_keys.

2) Create a key pair. The example here creates a Ed25519 key pair in the directory ~/.ssh.  The option -t assigns the key type and the option -f assigns the key file a name.  It is good to give keys files descriptive names, especially if larger numbers of keys are managed.  Below, the public key will be named mykey_ed25519.pub and the private key will be called mykey_ed25519.  Be sure to enter a sound passphrase to encrypt the private key using 128-bit AES.

Ed25519, Ed25519-SK, and ECDSA-SK keys have a fixed length. For RSA and ECDSA keys, the -b option sets the number of bits used. Since 6.5 a new private key format is available using a bcrypt(3) key derivative function (KDF) to better protect keys at rest. This new format is always used for Ed25519 keys, and sometime in the future will be the default for all keys. But for right now it may be requested when generating or saving existing keys of other types via the -o option in ssh-keygen(1).

Details of the new format are found in the source code in the file PROTOCOL.key.

3) Get the keys to the right places. Transfer only the public key to remote machine.

If ssh-copy-id(1) is not available, any editor that does not wrap long lines can be used. For example, nano(1) can be started with the -w option to prevent wrapping of long lines. Or another way to set that permanently is by editing nanorc(5)  However the authorized_keys file is edited to add the key, the key itself must be in the file whole and unbroken on a single  line.

Then if they are not already on the client, transfer both the public and private keys there. It is usually best to keep both the public and private keys together in the directory ~/.ssh/, though the public key is not needed on the client after this step and can be regenerated if it is ever needed again.

4) Test the keys

While still logged in, use the client start another SSH session in a new window and try authenticating to the remote machine from the client using the private key.

The option -i tells ssh(1) which private key to try. Close the original SSH session only after verifying that the key-based authentication works.

Once key-based authentication has been verified to be working, it is possible to make permanent shortcuts on the client using ssh_config(5), explained further below. In particular, see the IdentityFile, IdentitiesOnly, and AddKeysToAgent configuration directives, to name three.

➥ Troubleshooting of Key-based Authentication:

If the server refuses to accept the key and fails over to the next authentication method (eg: "Server refused our key"), then there are several possible mistakes to look for on the server side.

One of the most common errors is that the file and directory permissions are wrong. The authorized key file must be owned by the user in question and not be group writable. Nor may the key file's directory be group or world writable.

Another mistake that can happen is if the key inside the authorized_keys file on the remote host is broken by line breaks or has other whitespace in the middle. That can be fixed by joining up the lines and removing the spaces or by recopying the key more carefully.

And, though it should go without saying, the halves of the key pair need to match. The public key on the server needs to match the private key held on the client. If the public key is lost, then a new one can be generated with the -y option, but not the other way around. If the private key is lost, then the public key should be erased as it is no longer of any use. If many keys are in use for an account, it might be a good idea to add comments to them. On the client, it can be a good idea to know which server the key is for, either through the file name itself or through the comment field. A comment can be added using the -C option.

On the server, it can be important to annotate which client they key is from if there is more than one public key there in an account. There the comment can be added to the authorized key file on the server in the last column if a comment does not already exist. Again, the format of the authorized keys file is given in the manual page for sshd(8) in the section "AUTHORIZED_KEYS FILE FORMAT". If the keys are not labeled they can be hard to match, which might or might not be what you want.

Associating Keys Permanently with a Server
A key can be specified at run time, but to save retyping the same paths again and again, the Host directive in ssh_config(5) can apply specific settings to a target host. In this case, by changing ~/.ssh/config it is possible to assign particular keys to be tried automatically whenever making a connection to that specific host. After adding the following lines to ~/.ssh/config, all that's needed is to type  to connect with the key for that server.

Below ~/.ssh/config uses different keys for server versus server.example.org,  regardless whether they resolve to the same machine. This is possible because the host name argument given to ssh(1) is not converted to a canonicalized host name before matching.

In this example the shorter name is tried first, but of course less ambiguous shortcuts can be made instead. The configuration file gets parsed on a first-match basis. So the most specific rules go at the beginning and the most general rules go at the end.

Encrypted Home Directories
When using encrypted home directories the keys must be stored in an unencrypted directory. That means somewhere outside the actual home directory which means sshd(8) needs to be configured appropriately to find the keys in that special location.

Here is one method for solving the access problem. Each user is given a subdirectory under /etc/ssh/keys/ which they can then use for storing their authorized_keys file. This is set in the server's configuration file /etc/ssh/sshd_config

Setting a special location for the keys opens up more possibilities as to how the keys can be managed and multiple key file locations can be specified if they are separated by whitespace. The user does not have to have write permissions for the authorized_keys file. Only read permission is needed to be able to log in. But if the user is allowed to add, remove, or change their keys, then they will need write access to the file to do that.

One symptom of having an encrypted home directory is that key-based authentication only works when you are already logged into the same account, but fails when trying to make the first connection and log in for the first time.

Sometimes it is also necessary to add a script or call a program from /etc/ssh/sshrc immediately after authentication to decrypt the home directory.

Passwordless Login
One way of allowing passwordless logins is to follow the steps above, but simply do not enter a passphrase when asked for one while creating the key. Note that using keys that lack a passphrase is very risky, so the key files should be very well protected and kept track of. That includes that they only be used as single-purpose keys as described below. Timely key rotation becomes especially important. In general, it is not a good idea to make a key without a passphrase. A better solution is to have a passphrase and work with an authentication agent in conjunction with a single-purpose key. Most desktop environments launch an SSH agent automatically these days. It will be visible in the SSH_AUTH_SOCK environment variable if it is. On accounts with an agent, ssh-add(1) can load private keys into an available agent.

Thereafter, the client will automatically check the agent for the key when appropriate. If there are many keys in the agent, it will become necessary to set IdentitiesOnly. See the above section on using ~/.ssh/config for that. See [OpenSSH/Cookbook/Public_Key_Authentication#Key-based_Authentication_Using_an_Agent Key-based Authentication Using an Agent] below.

Requiring Both Keys and a Password
While users should have strong passphrases for their keys, there is no way to enforce or verify that. Indeed, since neither the private key nor its the passphrase ever leave the client machine there is nothing that the server can do to have any influence over that. Instead, it is possible to require both a key and a password. Starting with OpenSSH 6.2, it is possible for the server to require multiple authentication methods for login using the AuthenticationMethods directive.

This example from http://man.openbsd.org/sshd_config.5 sshd_config(5)] requires that users first authenticate using a key and it only queries for a password if the key succeeds. Thus with that configuration it is not possible to get to the system password prompt without first authenticating with a valid key. Changing the order of the arguments changes the order of the authentication methods.

Requiring Two or More Keys
Since OpenSSH 6.8, the server now remembers which public keys have been used for authentication and refuses to accept previously-used keys. This allows a set up requiring that users authenticate using two different public keys, maybe one in the file system and the other in a hardware token.

The AuthenticationMethods directive, whether for keys or passwords, can also be set on the server under a Match directive to apply only to certain groups or situations.

Requiring Certain Key Types For Authentication
Also since OpenSSH 6.8, the PubkeyAcceptedKeyTypes directive, later changed to PubkeyAcceptedAlgorithms, can specify which key algorithms are accepted for authentication. Those not in the comma-separated pattern list are not allowed.

Either the actual key types or a pattern can be in the list. Spaces are not allowed in the pattern list. The exact list of key types supported for authentication can be found by the -Q option using the client. The following two lines are equivalent.

For host-based authentication, it is the HostbasedAcceptedAlgorithms directive which determines the key types which are allowed for authentication.

Key-based Authentication Using an Agent
When an authentication agent, such as ssh-agent(1), is going to be used, it should generally be started at the beginning of a session and used to launch the login session or X-session so that the environment variables pointing to the agent and its UNIX-domain socket are passed to each subsequent shell and process. Many desktop distros do this automatically upon login or startup.

Starting an agent entails setting a pair of environment variables:

 * SSH_AGENT_PID : the process id of the agent
 * SSH_AUTH_SOCK : the filename and full path to the UNIX-domain socket

The various SSH and SFTP clients find these variables automatically and use them to contact the agent and try when authentication is needed. However, it is mainly SSH_AUTH_SOCK which is ever used. If the shell or desktop session was launched using ssh-agent(1), then these variables are already set and available. If they are not available, then it is necessary to either set the variables manually inside each shell or for each application in order to use the agent or else to point to the agent's socket using the directive IdentityAgent in the client's configuration file.

Once an agent is available, a relevant private key needs to be loaded before the agent can be used. Once in the agent the private key can then be used many times. Private keys are loaded into an agent with ssh-add(1).

Keys stay in the agent for as long as it is running unless specified otherwise. A timeout can be set either with the -t option when starting the agent itself or when actually loading the key using ssh-add(1). In either case, the -t option will set a timeout interval, after which the key will be purged from the agent.

The option -l will list the fingerprints of all of the identities in the agent.

It is also possible to remove individual identities from the agent using -d which will remove them one at a time if identified by file name, but only if the file name is given and without the file name of the private key to be remove, -d will fail silently. Using -D instead will remove all of them at once without needing to specify any by name.

By default ssh-add(1) uses the agent connected via the socket named in the environment variable SSH_AUTH_SOCK, if it is set. Currently, that is its only option. However, for ssh(1) an alternative to using the environment variable is the client configuration directive IdentityAgent which tells the SSH clients which socket to use to communicate with the agent. If both the environment variable and the configuration directive are available at the same time, then the value in IdentityAgent takes precedence over what's in the environment variable. IdentityAgent can also be set to none to prevent the connection from trying to use any agent at all.

The client configuration directive AddKeysToAgent can also be useful in getting keys into an agent as needed. When set, it automatically loads a key into a running agent the first time the key is called for if it is not already loaded. Likewise the IdentitiesOnly directive can ensure that the relevant key is offered on the first try. Rather than typing these out whenever the client is run, they can be added to ~/.ssh/config and thereby added automatically for designated host connections.

Agent Forwarding
Agent forwarding is one means of passing through one or more intermediate hosts. However, the -J option for ProxyJump would be a safer option. See Passing Through a Gateway or Two in the section on jump hosts about that. With agent forwarding, intermediate machines forward challenges and responses back and forth between the client and the final destination. This comes with some risks but eliminates the need for using passwords or holding keys on any of these intermediate machines.

A main advantage of agent forwarding is that the private key itself is not needed on any remote machine, thus hindering unwanted file system access to it. Another advantage is that the actual agent to which the user has authenticated does not go anywhere and is thus less susceptible to analysis.

One risk with agents is that they can be re-used to tailgate in if the permissions allow it. Keys cannot be copied this way, but authentication is possible when there are incorrect permissions. Note that disabling agent forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

The risks of agent forwarding can be mitigated by confirming each use of a key by adding the -c option when adding the key to the agent. This requires the SSH_ASKPASS variable be set and available to the agent process, but will generate a prompt on the host running the agent upon each use of the key by a remote system. So if passing through one or more intermediate hosts, it is usually better to instead have the SSH client use stdio forwarding with -W or -J.

On the client side agent forwarding is disabled by default and so if it is to be used it must be enabled explicitly. Put the following line in ssh_config(5) to enable agent forwarding for a particular server:

On the server side the default configuration files allow authentication agent forwarding, so to use it, nothing needs to be done there, just on the client side. However, again, it would be preferable to take a look at ProxyJump instead.

Old Style, Somewhat Safer SSH Agent Forwarding
The best way to pass through one or more intermediate hosts is to use the ProxyJump option instead of authentication agent forwarding and thereby not risk exposing any private keys. If authentication agent forwarding must be used, then it would be advisable in the interest of following the principle of least privilege to forward an agent containing the minimum necessary number of keys. There are several ways to solve that.

In version 8.8 and earlier a partial solution is to make a one-off, ephemeral agent to hold just the one key or keys needed for the task at hand. Another partial solution would be to set up a user-accessible service at the operating system level and then use ssh_config for the rest.

Automatically launching an ephemeral agent unique to each session can be done by crafting either a special shell alias or function to launch a single-use agent. Either the function or the alias can be written to require confirmation for each requested signature. The following example is an alias is based on an updated blog post by Vincent Bernat on SSH agent forwarding:

Note the use of ssh-agent(1). When invoking that alias, the SSH client will be launched with a unique, ephemeral supporting key agent. The alias sets up a new agent, including setting the two environment variables, and then sets two client options while calling the client. This arrangement still checks with ssh_config(5) for other options and settings. When the SSH session is finished the agent which launched it ends and goes away, thus cleaning up after itself automatically.

Another way is to rely on the client's configuration file for some of the settings. Such methods rely mostly on ssh_config(5) but still require an independent method to launch an ephemeral agent because the OpenSSH client is already running by the time it reads the configuration file and is thus not affected by any changes to environment variables caused by the configuration file and it is through the environment variables that contain information about the agent. However, when the path to the UNIX-domain socket used to communicate with the authentication agent is decided in advance then the IdentityAgent option can point to it once the one-off agent is actually launched. The following uses a specific agent's pre-defined socket whenever connecting to either of two particular domains:

The %d stands for the path to the home directory and the %i stands for the user id (UID) for the current account. In some cases the %i token might also come in handy when setting the IdentityAgent option inside the configuration file. Again, be careful when forwarding agents with which keys are in the forwarded agent. See the section "TOKENS" in ssh_config(5) for more such abbreviations.

With those configuration settings, the authentication agent must already be up and running and point to the designated socket prior to starting the SSH client for that configuration to work. Additionally, it should place the socket in a directory which is inaccessible to any other accounts. ssh-agent(1) must use the -a option to name the socket:

That agent configuration can be launched manually or via a script or service manager. However, in the interests of privacy and security in general, agent forwarding is to be avoided. The configuration directive ProxyJump is the best alternative and, on older systems, host traversal using ProxyCommand with netcat are preferable. Again, see the section on Proxies and Jump Hosts for how those methods are used.

New Style SSH Agent Destination Constraints
From 8.9 onward, ssh-agent(1) will allow the agent to limit which hosts they will be used for authentication as specified by ssh-add(1) using the -h option. These constraints have been added through two agent protocol extensions and a modification to the public key authentication protocol. This feature may evolve, but for now the result is such that keys for account authentication can be loaded into the agent in four ways:

 * no limits on forwarding (not recommended)
 * local use only, these will not get forwarded
 * forwarding, but only to specific remote hosts
 * forwarding to specific remote hosts via specified routes

The intent is that the restrictions fail safely so that they do not allow authentication when one or more hosts in the route lack the needed protocol features. The destinations and routes cannot be modified once the keys are loaded, but multiple routes to the same destination can be loaded and the routes can be any number of hops. If the routes need changing, then the key must be reloaded into the agent with the new route or routes.

The general default for the client is to keep keys in the agent for local use only. However, that can be enforced explicitly by adding the -a option when starting the client or else setting the ForwardAgent directive in ssh_config(5) to 'no' in the relevant configuration block.

In order to load keys for unlimited forwarding, which is not the best idea, just add them using ssh-add(1) as normal. Then use the -A option with the client or set the ForwardAgent directive in ssh_config(5) to 'yes' in the relevant configuration block.

In order to limit keys for connection only to a specific remote host, or to load keys for connection to a specific remote host with forwarding via one or more intermediate hosts, use he -h option when loading keys into the agent. Here the one key may be used only to connect to the specific destination:

If an intermediate system is passed through, the best way is to use ProxyJump which is the -J option for the SSH Client. If agent forwarding must be allowed then the tightest way is to constrain which systems may use the keys, again using the -h option.

Multiple steps can be included, even multiple routes. They just have to be enumerated explicitly, though patterns may still be used for the destination hosts as well as specific names. Each host in the chain must support these protocol extensions for the connection to complete.

Any keys designated for forwarding are unusable for authentication on any other hosts than those which have been explicitly identified for forwarding. These permitted hosts are identified by host key or host certificate from the known_hosts file or another file designated by the -H option when loading the key with ssh-add(1). If -H is not used at the time the keys are loaded into the agent, then the default known hosts file(s) will be used: ~/.ssh/known_hosts, /etc/ssh/ssh_known_hosts, ~/.ssh/known_hosts2, and /etc/ssh/ssh_known_hosts2.

In the case of keys, the known_hosts list must be maintained conscientiously, perhaps with the help of the UpdateHostkeys and CanonicalizeHostname client configuration directives. Use of certificates requires the agent to only need to be aware of the Certificate Authority (CA).

Again, see Passing Through a Gateway or Two in the section on jump hosts about a way to pass through one or more intermediate machines without needing to forward an SSH agent.

Checking the Agent for Specific Keys
The ssh_add(1) utility's -T option can test whether a specific private key is available in the agent or not by looking up the matching public key. That can be useful in a shell script.

Or it could be done with an alternate syntax just as well either in a script or in an interactive shell sessions,

However, if the desired result would be to add key to the agent then the AddKeysToAgent client configuration option can ensure that a specific key is added to the SSH agent upon first use during any given login session. That can be done using -o AddKeysToAgent=yes as a run-time argument, or by modifying ssh_config(5) as appropriate:

With those options in the configuration file, the first time  is run the specified key will get added to the agent and remain available.

Key-based Authentication Using A Hardware Security Token
While stand-alone keys have been around for a long time, it has been possible since version 8.2 to use keys backed by hardware security tokens, such as OnlyKey, Yubikey, or many others, though the FIDO2 protocol. The Universal 2nd Factor (U2F) authentication is supported directly in OpenSSH through FIDO2 and does not need third party software. At the moment there are two types of hardware backed keys, ECDSA-SK and Ed25519-SK, but only the latest hardware tokens support the latter. If the key Ed25519-SK format is not supported by the token's firmware, then the following error message will be presented when attempts to use that key type are made:

If supported, either key type can be created with ssh-keygen(1). The steps are almost identical to creating normal keys but the token must be available to the system (plugged in) first. Then if called for, the token's PIN must be entered and the token touched or otherwise activated. After that, the key creation proceeds as normal. Mind the key type as specified by the -t option.

Once created, the public and private key files get handled like with any other type of key. But when authenticating, the hardware token must be present and activated when called for.

The resulting private key file is not actually the key itself but instead a "key handle" which is used by the hardware security token to derive the real private key on demand at the time it is actually used. As a result, the hardware-backed private key file is useless without the accompanying hardware token. This also means that these key files are not portable across hardware tokens, say when having multiple tokens in reserve or as backup, even when used by the same account. So when multiple hardware tokens are in use, different key pairs must be generated for each token.

Hardware Security Token Resident Private Key
It is possible to store the private key within the token itself, but for the moment it cannot be used directly from inside the token and must first be saved as a file. Also, the key can only be loaded into the FIDO authenticator at the time of creation using the -O resident option with ssh-keygen(1). Otherwise, the process is the same as above.

When needed, the resident key can be extracted from the FIDO2 hardware token and saved into a file using the -K option. At this stage a passphrase can be added to the file, but no passphrase is kept within the token itself, only an optional PIN protects the key there.

Since the output file name is fixed, any pre-existing file with that name can get overwritten but there will be a warning first. However, it is not recommended to keep the key on the hardware token because it provides more protection when kept separately.

Single-purpose Keys
Tailored single-purpose keys can eliminate use of remote root logins for many administrative activities. A finely tailored sudoers is needed along with an unprivileged account. When done right, it gives just enough access to get the job done, following the security principle of Least Privilege.

Single-purpose keys are accompanied by use of either the ForceCommand directive in sshd_config(5) or the command="..." directive inside the authorized_keys file. The method is to generate a new key pair, transfer the public key to authorized-keys on the remote system, and then prepend the appropriate command or script there to the line with the key.

The command="..." directive inserted there overrides everything else and ensures that when logging in with just that key only the script /usr/local/bin/somescript.sh is run. If it is necessary to pass parameters to the script, have a look at the contents of the SSH_ORIGINAL_COMMAND environment variable and use it in a case statement. Do not ever trust the contents of that variable nor use the contents directly, always indirectly.

Single-purpose keys are useful for allowing only a tunnel and nothing more. The following key will only echo some text and then exit, unless used non-interactively with the -N option.

No matter what the user tries while logging in with that key, the session will only echo the given text and then exits. Using the -N option disables running the remote program, allowing the connection to stay open, allowing a tunnel.

That creates a tunnel and stays connected despite a key configuration which would close an interactive session. See also the -n or -f option for ssh(1).

Single-purpose Keys to Avoid Remote Root Access
The easy way is to write a short shell script, place it /usr/local/bin/, and then configure sudoers to allow the otherwise unprivileged account to run just that script and only that script.

Then the key calls the script using command="..." inside authorized_keys. Here the one key starts the web server, the other stops the web server.

Complicated programs like rsync(1), tar(1), mysqldump(1), and so on require an advanced approach when building a single-purpose key. For them, the -v option can show exactly what is being passed to the server so that sudoers can be set up correctly. That way they can be restricted to only access designated parts of the file system. For example, here is what  shows from one particular usage of rsync(1), note the "Sending command" line:

That output can then be added to sudoers so that the key can do only that function.

Then to tie it all together, the account "backup" needs a key:

Many of these programs have a ---dry-run or equivalent option. Remember to use it when figuring out the right settings.

Read-only Access to Keys
In some cases it is necessary to prevent accounts from being able to changing their own authentication keys. However, such situations may be a better case for using certificates. However, if done with keys it is accomplished by putting the key file in an external directory where the user has read-only access, both to the directory and to the key file. Then the AuthorizedKeysFile directive assigns where sshd(8) looks for the keys and can point to a secured location for the keys instead of the default location.

A good alternate location could be a new directory /etc/ssh/authorized_keys which could store the selected accounts' key files there. The change can be made to apply to only a group of accounts by putting the settings under a Match directive. The default location for keys on most systems is usually ~/.ssh/authorized_keys.

Then the permissions there would allow the keys to be read but not written:

The keys could even be in within subdirectories, though the same restrictions apply regarding permissions and ownership.

For chrooted SFTP, the method is the same to keep the key files out of reach of the accounts:

Of course a Match directive is not essential. The settings could be made to apply to all accounts by putting the directive in the main part of the server configuration file instead.

Mark Public Keys as Revoked
Keys can be revoked. Keys that have been revoked can be stored in /etc/ssh/revoked_keys, a file specified in sshd_config(5) using the directive RevokedKeys, so that sshd(8) will prevent attempts to log in with them. No warning or error on the client side will be given if a revoked key is tried. Authentication will simply progress to the next key or method.

The revoked keys file should contain a list of public keys, one per line, that have been revoked and can no longer be used to connect to the server. The key cannot contain any extras, such as login options or it will be ignored. If one of the revoked keys is tried during a login attempt, the server will simply ignore it and move on to the next authentication method. An entry will be made in the logs of the attempt, including the key's fingerprint. See the section on logging for a little more on that.

The RevokedKeys configuration directive is not set in sshd_config(5) by default. It must be set explicitly if it is to be used. This is another situation that might be better fulfilled through using certificate since a validity interval can be set in any combination of seconds, minutes, hours, days, or weeks can be set for certificates while keys are valid indefinitely.

Key Revocation Lists
A Key Revocation List (KRL) is a compact, binary form of representing revoked keys and certificates. In order to use a KRL, the server's configuration file must point to a valid list using the RevokedKeys directive. KRLs themselves are generated with ssh-keygen(1) and can be created from scratch or edited in place. Here a new one is made, populated with a single public key:

Here an existing KRL is updated by adding the -u option:

Once a KRL is in place, it is possible to test if a specific key or certificate is in the revocation list.

Only public keys and certificates will be loaded into the KRL. Corrupt or broken keys will not be loaded and will produce an error message if tried. Like with the regular RevokedKeys list, the public key destined for the KRL cannot contain any extras like login options or it will produce an error when an attempt is made to load it into the KRL or search the KRL for it.

Verify a Host Key by Fingerprint
The above examples have been about using keys to authenticate the client to the server. A different context in which keys are used is when the server identifies itself to the client, which happens automatically at the beginning of each non-multiplexed session. In order for that identification to happen the client acquires a public key from the server, usually on or prior to first contact, which it can subsequently use to ensure that it is connecting to the same server again and not an impostor. The default locations for storing these acquired host keys on the client are in /etc/ssh/ssh_known_hosts, if managed by the system administrator, or in ~/.ssh/known_hosts if managed by the client's own account. The format of the contents is a line with a host address and its matching public key. The file is described in detail in the sshd(8) manual page in the section "SSH_KNOWN_HOSTS FILE FORMAT".

When connecting for the first time to a remote host, the server's host key should be verified in order to ensure that the client is connecting to the right machine and not an impostor or anything else. Usually this verification is done by comparing the fingerprint of the server's host key rather than trying to compare the whole key itself. By default the client will show the fingerprint if the key is not already found in the known_hosts register.

That can be compared to a fingerprint received out of band, say by post, e-mail, SMS, courier, and so on. Specifically, the example represents the key's fingerprint as a base64 encoded SHA256 checksum. That is the default style. The fingerprint can also be displayed as an MD5 hash in hexadecimal instead by passing the client's FingerprintHash configuration directive as a runtime argument or setting it in ssh_config(5).

But the default in new versions is SHA256 in base64 has a lower chance of collision.

In OpenSSH 6.7 and earlier, the client showed fingerprints as a hexadecimal MD5 checksum instead a of the base64-encoded SHA256 checksum currently used:

Another way of comparing keys is to use the ASCII art visual host key. See further below about that.

Downloading keys
Even though a host’s key is usually displayed for review the first time the SSH client tries to connect, it can also be fetched on demand at any time using ssh-keyscan(1):

Once a key is acquired, its fingerprint can be shown using ssh-keygen(1). This can be done directly with a pipe.

If there is more than one public key type is available from the server on the port polled, then ssh-keyscan(1) will fetch each of them. If there is more than one key fed via stdin or a file, then ssh-keygen(1) will process them in order. Prior to OpenSSH 7.2 manual fingerprinting was a two step process, the key was read to a file and then processed for its fingerprint.

Note that some output from ssh-keyscan(1) is sent to stderr instead of stdout.

A hash, or fingerprint, can be generated manually with awk(1), sed(1) and xxd(1), on systems where they are found.

It is possible to find all hosts from a file which have new or different keys from those in known_hosts, if the host names are in clear text and not stored as hashes.

Using ssh-keyscan(1) with ssh_config(5)
The utility ssh-keyscan(1) does not parse ssh_config(5). That is in part to keep the code base simple. There are a lot of configuration options which would be complicated to implement, including but not limited to ProxyJump, ProxyCommand, Match, BindInterface, and CanonicalizeHostname. Resolving host names via the client configuration file can be done by wrapping the utility in a short shell function:

That shell function uses the -G option of ssh(1) to resolve each host name using ssh_config(5) and then check the resulting host name for SSH keys.

ASCII Art Visual Host Key
An ASCII art representation of the key can be displayed along with the SHA256 base64 fingerprint:

In OpenSSH 6.7 and earlier the fingerprint is in MD5 hexadecimal form.

More on Verifying SSH Keys
Keys on the client or the server can be verified against known good keys by comparing the base64-encoded SHA256 fingerprints.

Verifying Stray Client Keys
Sometimes is is necessary to compare two uncertain key files to check if they are part of the same key pair. However, public keys are more or less disposable. So the easy way in such situations on the client machine is to just rename or erase the old, problematic, public key and replace it with a new one generated from the existing private key.

But if the two parts must really be compared, it is done in two steps using ssh-keygen(1). First, a new public key is re-generated from the known private key and used to make a fingerprint to stdout. Next, the fingerprint of the unknown public key is generated for comparison. In this example, the private key my_key_a_rsa and the public key my_key_b_rsa.pub are compared:

The result is a base64-encoded SHA256 checksum for each key with the one fingerprint displayed right below the other for easy visual comparison. Older versions don't support reading from stdin so an intermediate file will be needed then. Even older versions will only show an MD5 checksum for each key. Either way, automation with a shell script is simple enough to accomplish but outside the scope of this book.

Verifying Server Keys
Reliable verification of a server's host key must be done when first connecting. It can be necessary to contact the system administrator who can provide it out of band so as to know the fingerprint in advance and have it ready to verify the first connection.

Here is an example of the server's RSA key being read and its fingerprint shown as SHA256 base64:

And here the corresponding ECDSA key is read, but shown as an MD5 hexadecimal hash:

Prior to 6.8, the fingerprint was expressed as an MD5 hexadecimal hash:

It is also possible to use ssh-keyscan(1) to get keys from an active SSH server. However, the fingerprints still needs to be verified out of band.

Warning: Remote Host Identification Has Changed!
If a server's key does not match what the client finds has been recorded in either the system's or the local account's authorized_keys files, then the client will issue a warning along with the fingerprint of the suspicious key.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:GkoIDP/d0I6KA9IQyOB9iqL+Rzpxx9LhlSJPCEfjVQ4. Please contact your system administrator. Add correct host key in /home/fred/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/fred/.ssh/known_hosts:19 remove with: ssh-keygen -f "/home/fred/.ssh/known_hosts" -R "server.example.com" RSA host key for server.example.com has changed and you have requested strict checking. Host key verification failed.

Three reasons for the warning are common.

One reason is that the server's keys were replaced, often because the server's operating system was reinstalled without backing up the old keys. Another reason can be when the system administrator has phased out deprecated or compromised keys. However that can be planned better and if there is time to plan the migration, new keys can just be added to the server and have the clients use the UpdateHostKeys option so that the new keys are accepted if the old keys match. A third situation is when the connection is made to the wrong machine, such as when the remote system changes IP addresses because of dynamic address allocation.

In all three cases where the key has changed there is only one thing to do: contact the system administrator and verify the key. Ask if the OpenSSH-server was recently reinstalled, or was the machine restored from an old backup? Keep in mind that the system administrator may be you yourself in some cases.

The case which is rather rare but serious enough that it should be ruled out for sure is that the wrong machine is part of a man-in-the-middle attack.

In all four cases, an authentic key fingerprint can be acquired by any method where it is possible to verify the integrity and origin of the message, for example via PGP-signed e-mail. If physical access is possible, then use the console to get the right fingerprint. Once the authentic key fingerprint is available, return to the client machine where you got the error and remove the old key from ~/.ssh/known_hosts

Then try logging in, but compare the key fingerprints first and proceed if and only if the key fingerprint matches what you received out of band. If the key fingerprint matches, then go through with the login process and the key will be automatically added. If the key fingerprint does not match, stop immediately and figure out what you are connecting to. It would be a good idea to get on the phone, a real phone not a computer phone, to the remote machine's system administrator or the network administrator.

Multiple Keys for a Host, Multiple Hosts for a Key in known_hosts
Multiple host names or IP addresses can use the same key in the known_hosts file by using pattern matching or simply by listing multiple systems for the same key. That can be done in either the global list of keys in /etc/ssh/ssh_known_hosts and the local, account-specific lists of keys in each account's ~/.ssh/known_hosts file. Labs, computational clusters, and similar pools of machines can make use of keys in that way. Here is a key shared by three specific hosts, identified by name: server1,server2,server3 ssh-rsa AAAAB097y0yiblo97gvl...jhvlhjgluibp7y807t08mmniKjug...== Or a range can be specified by using globbing to a limited extent in either /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts. 172.19.40.* ssh-rsa AAAAB097y0yiblo97gvl...jhvlhjgluibp7y807t08mmniKjug...== Conversely, for multiple keys for the same address, it is necessary to make multiple entries in either /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts for each key. server1 ssh-rsa AAAAB097y0yiblo97gvljh...vlhjgluibp7y807t08mmniKjug...== server1 ssh-rsa AAAAB0liuouibl kuhlhlu...qerf1dcw16twc61c6cw1ryer4t...== server1 ssh-rsa AAAAB568ijh68uhg63wedx...aq14rdfcvbhu865rfgbvcfrt65...== Thus in order to get a pool of servers to share a pool of keys, each server-key combination must be added manually to the known_hosts file: server1 ssh-rsa AAAAB097y0yiblo97gvljh...07t8mmniKjug...== server1 ssh-rsa AAAAB0liuouibl kuhlhlu...qerfw1ryer4t...== server1 ssh-rsa AAAAB568ijh68uhg63wedx...aq14rvcfrt65...==

server2 ssh-rsa AAAAB097y0yiblo97gvljh...07t8mmniKjug...== server2 ssh-rsa AAAAB0liuouibl kuhlhlu...qerfw1ryer4t...== server2 ssh-rsa AAAAB568ijh68uhg63wedx...aq14rvcfrt65...==

Though upgrading to certificates might be a more appropriate approach that manually updating lots of keys.

Another way of Dealing with Dynamic (roaming) IP Addresses
It is possible to manually point to the right key using HostKeyAlias either as part of ssh_config(5) or as a runtime parameter. Here the key for machine Foobar is used to connect to host 192.168.11.15

This is useful when DHCP is not configured to try to keep the same addresses for the same machines over time or when using certain stdio forwarding methods to pass through intermediate hosts.

Hostkey Update and Rotation in known_hosts
A protocol extension to rotate weak public keys out of known_hosts has been in OpenSSH from version 6.8 and later. With it the server is able to inform the client of all its host keys and update known_hosts with new ones when at least one trusted key already known. This method still requires the private keys be available to the server so that proofs can be completed. In ssh_config(5), the directive UpdateHostKeys specifies whether the client should accept updates of additional host keys from the server after authentication is completed and add them to known_hosts. A server can offer multiple keys of the same type for a period before removing the deprecated key from those offered, thus allowing an automated option for rotating keys as well as for upgrading from weaker algorithms to stronger ones. See also RFC 4819: Secure Shell Public Key Subsystem about key management standards.


text:
User:Swapnil durgade/Crontab Format

Crontab format * * * * * command to be executed - - - - - | | | | | | | | | - day of week (0 - 6) (Sunday=0) | | | --- month (1 - 12) | | - day of month (1 - 31) | --- hour (0 - 23) - min (0 - 59)

-Swapnil (Friday, December 09, 2005) Email- swapnil_durgade@yahoo.com

title: User:Swapnil durgade/Crontab Format


text:
User:Swapnil durgade/Masquerade domain in postfix - Swapnil

You have postfix server on machine smtp.india.thoughtworks.com. You want to all outgoing emails should appear to be sent from domain thoughworks.com.

open vi /etc/postfix/main.cf and add line masquerade_domains = thoughtworks.com

-Swapnil (Friday, December 09, 2005) Email- swapnil_durgade@yahoo.com


text:
Linux Guide/LDAP authentication in Linux

Tested on Fedora Core 4 only

1. Install following RPMs openldap-2.2.23-5.i386.rpm openldap-clients-2.2.23-5.i386.rpm openldap-servers-2.2.23-5.i386.rpm

2. Configure and Start OpenLDAP Edit file /etc/openldap/slapd.conf and change 3 settings 1. suffix "dc=example,dc=com" 2. rootdn "cn=manager,dc=example,dc=com" 3. rootpw yourrootpassword To Start OpenLDAP run command  service ldap start

3. Use Migration Script to create ldif files from /etc/passwd and /etc/group

Go to directory /usr/share/openldap/migration

edit migrate_common.ph and change 2 settings

1. $DEFAULT_MAIL_DOMAIN = "example.com"; 2. $DEFAULT_BASE = "dc=example,dc=com";

Create 3 ldif files in /root directory with following commands

./migrate_group.pl /etc/group /root/group.ldif ./migrate_passwd.pl /etc/passwd /root/passwd.ldif ./migrate_base.pl > /root/base.ldif

4. Import ldif files into OpenLDAP

ldapadd -cx -D "cn=manager,dc=example,dc=com" -w yourrootpassword -f /root/base.ldif ldapadd -cx -D "cn=manager,dc=example,dc=com" -w yourrootpassword -f /root/passwd.ldif ldapadd -cx -D "cn=manager,dc=example,dc=com" -w yourrootpassword -f /root/group.ldif

5. Use authconfig to configure Linux for ldap authentication as root, run command authconfig on first screen, select Use LDAP and Use LDAP Authentication On Next screen, Type Server: 127.0.0.1 Base DN: dc=example,dc=com

-Swapnil (Friday, December 09, 2005) Email- swapnil_durgade@yahoo.com


text:
Cryptography/Notes

'Cryptography is a Greek word which means "Secret Writing"

Important Uses of Cryptography 1. Protect confidentiality of message (Achieved with Encryption Algorithms) 2. Provide identity for authentication (Achieved with Asymmetric Encryption Algorithms, digital signature algorithms) 3. Verify information to check message integrity (Achieved with hash functions)

To Validate information cryptographic function are used.

Cryptographic functions are called as hash functions

e.g. of Hash Functions 1. MD5 (Message Digest 5) 2. SHA (Secure Hash Algorithm)

Types of Cryptography 1. Secret key cryptography (Both parties know the same secret key. Uses symmetric encryption) 2. Public key cryptography (Both parties have 2 different keys,Public key for encryption and Private key for decryption.

Private key for signing, public key for signature verification.

In Reversible public key algorithms, Data encrypted with private key can be decrypted with public key.Uses asymmetric encryption)

Encryption algorithms are called Ciphers Information in encrypted form is called Ciphertext

2 Types of Ciphers 1. Stream Ciphers (Process data byte at a time) 2. Block Ciphers (Process data in blocks 8 bytes at a time. Pad packets smaller than block)

e.g. of Symmetric Encryption Algorithms

1. DES (Data Encryption Standard - Block) 2. 3DES (Triple strength Data Encryption Standard - Block) 3. RC2 (Rivest Cipher 2 - Block) 4. RC4 (Rivest Cipher 4 - Stream)

e.g. of Asymmetric Encryption Algorithms

1. RSA - Rivest Shamir Adleman 2. DSA - Digital Signature Algorithm - Can only be used for digital signatures.

title: Cryptography/Notes


text:
Talk:Automatic Control Engineering

We should also inlude a lab component with MatLab projects.

title: Talk:Automatic Control Engineering


text:
User talk:Ddp~enwikibooks

Free screenshots
Can you fix your images? You just have to change to. --Derbeth talk 09:11, 8 December 2005 (UTC)

Deletion of Page
Please don't blank pages that you want to delete. It causes us no end of grief here and with other Wikimedia projects. If you can, please use the   markup template on the page if you want to delete something from here. We will find the page sooner and be able to deal with the deletion without having to fight through other pages first.

Thank you, though, for trying to help make Wikibooks a better place. We do appreciate people like you trying to help find stuff that really doesn't belong. --Rob Horning 19:15, 23 January 2006 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Ddp. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Ddp~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:04, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 04:52, 19 April 2015 (UTC)

title: User talk:Ddp~enwikibooks


text:
User:0.39~enwikibooks

-

title: User:0.39~enwikibooks