Wil je meedoen?

Wil je ook dat jouw weblog wordt opgenomen op Linuxweblogs? Neem dan contact op via onze contactpagina. Alleen Nederlandstalige weblogs die schrijven over Linux of open source komen in aanmerking voor syndication.

Volg ons en laat van je horen via Twitter

www.twitter.com/linuxweblogs

Volg ons op Twitter en communiceer met andere belangstellenden van het Linux besturingssyteem.

Geen weblog en toch mee willen doen?

Als het je ook leuk lijkt om ook af en toe een bijdrage te leveren voor dit project dan kan je altijd contact opnemen. Je kan dan via deze website je ervaringen kwijt. Of schrijf je liever een column? Laat maar weten.

Author Archive

Feb
08

SSH display problemen getackeld

Posted by: Ton Kersten | Comments (0)

AT Computing heeft enige tijd geleden besloten over te gaan op een compleet nieuwe infrastructuur. Het gewone, bekende spul, zoals een SAN, virtualisatie en Linux.

Nu heb ik aardig wat van die systemen ingericht en geconfigureerd en ik wilde op een duidelijke manier kunnen zien op welke server ik zat. Nu kan dat in de prompt en op allerlei andere manieren, maar mij leek het leuk om dat voor het daadwerkelijke inloggen te doen. Met SSH is het mogelijk om in de configuratie te zetten dat er voor het inloggen een banner wordt getoond. Dit is van oorsprong bedoeld om juridische teksten over het gebruik van het systeem te tonen, maar dat kun je natuurlijk ook voor andere zaken gebruiken.

Nu alleen nog de inhoud van de banner file. Hiervoor heb ik het programma Figlet gebruikt en wanneer ik nu inlog op de server zou het er zo uit moeten zien:

 _ __ ___  _   _ ___  ___ _ ____   _____ _ __ 
| '_ ` _ \| | | / __|/ _ \ '__\ \ / / _ \ '__|
| | | | | | |_| \__ \  __/ |   \ V /  __/ |   
|_| |_| |_|\__, |___/\___|_|    \_/ \___|_|   
           |___/

Maar zo af en toe als ik in log staat er niet wat ik verwacht, maar

 _ __ ___  _   _ ___  ___ _ ____   _____ _ __ 
| '_ ` _ \\| | | / __|/ _ \\ '__\\ \\ / / _ \\ '__|
| | | | | | |_| \\__ \\  __/ |   \\ V /  __/ |   
|_| |_| |_|\\__, |___/\\___|_|    \\_/ \\___|_|   
           |___/

Nou, dat is niet wat ik bedoel. Alle backslashes worden verdubbeld en ik weet nog niet waarom. Discussie met collega's stuurde me richting het programma mingetty, omdat dat de inlog procedure afhandelt. Op ons CentOS 5.4 systeem staat in de source code van mingetty

if ((fd = fopen (ISSUE, "r"))) {
    while ((c = getc (fd)) != EOF) {
        if (c == '\\')
            output_special_char (getc(fd));
        else
            putchar (c);
    }
    fflush (stdout);
    fclose (fd);
}

dus dat zou het best wel eens kunnen zijn.

Om nu niet direct mingetty opnieuw te compileren en allerlei andere problemen te veroorzaken, heb ik als eerste test een mingetty escape code in de banner file opgenomen. Bij het inloggen werd die niet door mingetty geparsed, dus dat kon de oorzaak niet zijn. Even verder nadenkend kwam ik tot de conclusie dat mingetty in het hele spel niet voor komt en dat dit dus een dood spoor is.
Dan zijn er niet meer zo heel veel opties over.

Uit de OpenSSH server source code bleek duidelijk dat daar het probleem niet kon zitten, omdat deze de banner file met een 'atomic write' naar de overkant stuurt. Daar zit dus geen enkele vorm van processing tussen.

Maar als het de server niet is, dan misschien de client. Verder zoekend in de source code toonde aan dat hier het probleem zou moeten zitten. In de file sshconnect2.c staat (in mijn versie, OpenSSH version 5.3p1) de functie input_userauth_banner die de banner laat zien die door de server gestuurd wordt. Op regel 417 staat:

strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL);

Dus "unsafe" characters en "octal" tekens worden gecodeerd. De manual pagina van strnvis zegt:

There is one additional flag, VIS_NOSLASH, which inhibits the doubling of backslashes and the backslash before the default format

Ik heb de regel dus veranderd in

strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL|VIS_NOSLASH);

en daarna SSH opnieuw gecompileerd. Als ik nu met deze nieuwe client inlog in de nieuwe server, dan is het probleem spoorloos verdwenen.

Toen ik dit probleem als bug report wilde aanmelden bij de OpenSSH ontwikkelaars bleek dat ongeveer een uur voor mij iemand anders dezelfde bug en patch al had ingediend. Het probleem zal worden opgelost in versie 5.4, maar het kan wel even duren voordat het in de distributies beschikbaar is.

Categories : Algemeen
Comments (0)