SSH - Login klappt, dann keine Eingabe mehr möglich

[anawak12]

Hallo,

ich versuche über das Terminal eine SSH-Verbindung zu meinem Server über PublicKey-Authentifizierung aufzubauen. Die Anmeldung scheint über den Befehl

ssh -l loginname server -p 2222 -v

(loginname und server ersetzt, sshd läuft auf Port 2222)

führt zu folgender Ausgabe:

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host server' is known and matches the RSA host key.
debug1: Found key in /Users/anawak/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/anawak/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

Ab diesem Zeitpunkt ist keine Eingabe mehr möglich. Wie gelange ich auf die Shell? Habe ich etwas übersehen?

Viele Grüße
anawak

 

[anawak12]

Achja, der Zugriff über SCP (CyberDuck) funktioniert reibungslos. Ebenfalls kann ich mich über andere Rechner und Betriebssysteme auf dem Server einloggen. Ich vermute, OpenSSH hat ein Problem eine gültige Shell zu öffnen. Nur wie löse ich das?

 

[Terminal]

In dem du dich auf eine andere Art und Weise mit dem Terminal am Server anmeldest. Nämlich so:

ssh deinName@ServerDomainName

oder

ssh ServerDomainName 22

Anschliessend wird automatisch das Passwort abgefragt und muss mit "Enter" bestätigt werden. Das Kennwort wird aber nicht angezeigt, auch keine Lückenfüller für die Eingabe.

Du solltest dich allerdings schon von extern anmelden, sonst kann dein System nicht genau unterscheiden ob du dich direkt anmeldest oder von außerhalb. Der Fingerprint und die Frage JA/NEIN wird nur im 2. Fall abgefragt, wenn das System merkt, dass du dich wirklich von ausserhalb anmeldest. Ich würde mir dazu einen Account bei DynDNS anlegen und meinen Host dann so anwählen:

ssh [email protected]

 

[anawak12]

Danke für deine Antwort, leider besteht das Problem auch mit der alternativen Syntax. :/

Anschliessend wird automatisch das Passwort abgefragt und muss mit "Enter" bestätigt werden.

Ich nutze PublicKeys, die ich nicht weiter mit einem Passwort geschützt habe.

Du solltest dich allerdings schon von extern anmelden, sonst kann dein System nicht genau unterscheiden ob du dich direkt anmeldest oder von außerhalb. Der Fingerprint und die Frage JA/NEIN wird nur im 2. Fall abgefragt, wenn das System merkt, dass du dich wirklich von ausserhalb anmeldest. Ich würde mir dazu einen Account bei DynDNS anlegen und meinen Host dann so anwählen:

Also ich melde mich von außerhalb an. Ich versuche auf meinen Webserver zu kommen.

Alles Gute
anawak

 

[anawak12]

Ich habe mir gerade die aktuelle Version von openssh.com
geladen und selbst kompiliert. Leider das gleiche Problem. Bin wirklich ratlos.

 

[Terminal]

Ist möglich, dass es an deiner internen Firewall oder an NAT deines Routers liegt, dass du einfach nicht korrekt durchkommst. Vom System her ist es ja Port 22 und nicht 2222. Und NAT deines Routers musst du natürlich auf einen internen Port deines Rechners umleiten. Das geschieht ja nicht automatisch.

 

[anawak12]

Ist möglich, dass es an deiner internen Firewall oder an NAT deines Routers liegt, dass du einfach nicht korrekt durchkommst. Vom System her ist es ja Port 22 und nicht 2222. Und NAT deines Routers musst du natürlich auf einen internen Port deines Rechners umleiten. Das geschieht ja nicht automatisch.

Wie weiter oben beschrieben, kann ich NAT-Probleme ausschließen, da der Zugriff von anderen Rechnern aus dem gleichen Netzwerk funktioniert. Selbst von dem MacBook aus funktioniert der Zugriff mit Putty über CrossOverOffice gestartet. (Was natürlich keine Dauerlösung ist) Den Port habe ich auf dem Webserver auf 2222 gelegt, damit meine Logfiles nicht mit Bruteforcegehämmere zumüllen.

Das Problem scheint tatsächlich damit zusammenzuhängen, dass OpenSSH keine Shell starten kann.
Das gleiche Problem wurde auch hier beschrieben, aber leider blieb es ebenfalls ungelöst.

Alles Gute
anawak

 

[Terminal]

Warum nutzt du denn nicht den in System X mitgelieferten SSH-Server und Client? Bei mir kann ich mich doch auch ohne weiteres anmelden.

Warum musst du dir etwas anderes nachträglich installieren, wenn es doch in MacOS X enthalten ist? Du weißt doch gar nicht was eine Doppelinstallation bewirken kann.

In OSX ist die Verwendung von SSH genau definiert, im Kontrollfeld Systemeinstellungen --> Sharing --> Entfernte Anmeldung. Dieser und andere Dienste werden aber dabei über launchd im System gestartet und bei ihrer Arbeit überwacht.

Was du jetzt gemacht hast, ist nicht nur bischen dumm, sondern auch gefährlich. Und ehrlich gesagt bin ich froh, dass es bei dir nicht funktioniert.

Eigentlich verstehe ich auch nicht recht, warum du dich mit dem ssh-Befehlszeilen-Tool auf deinem Webserver anmelden willst. Beide Datenvermittlungsstellen haben überhaupt nichts miteinander gemein und arbeiten völlig unabhängig voneinander.

Der Webserver dient der Zurverfügungstellung und Darstellung von HTML-Seiten auf Seiten der Clients und SSH ist eine Schnittstelle um sich entfernt an einem Rechnerport anzumelden um entweder Daten zu übertragen oder Befehlszeilen auszuführen, wie einen Neustart eines Rechners.

Verwechselst du vielleicht da etwas? Vielleicht meinst du ja OpenSSL? Die sichere Übertragung der Daten durch den Webserver?

 

[anawak12]

Warum nutzt du denn nicht den in System X mitgelieferten SSH-Server und Client? Bei mir kann ich mich doch auch ohne weiteres anmelden.

Warum musst du dir etwas anderes nachträglich installieren, wenn es doch in MacOS X enthalten ist? Du weißt doch gar nicht was eine Doppelinstallation bewirken kann.

Ich befürchte, du hast mich falsch verstanden. Ich habe den mitgelieferten SSH-Client versucht zu nutzen, weil ich dringend Zugriff auf meinen Webserver nehmen musst. (Der steht nicht in meinem LAN, sondern bei meinem Hoster) Dabei stellte sich das oben beschriebene Problem ein.

Was du jetzt gemacht hast, ist nicht nur bischen dumm, sondern auch gefährlich. Und ehrlich gesagt bin ich froh, dass es bei dir nicht funktioniert.

Warum wirst du eigentlich ausfallend und beleidigend? Was daran dumm und gefährlich sein soll einen alternativen SSH-Client zu nutzen, wenn der mitgelieferte nicht funktioniert, wüsste ich auch nicht.

 

[anawak12]

Eigentlich verstehe ich auch nicht recht, warum du dich mit dem ssh-Befehlszeilen-Tool auf deinem Webserver anmelden willst.

Im Moment um meinen Postfix auf dem Webserver zu updaten.

Verwechselst du vielleicht da etwas? Vielleicht meinst du ja OpenSSL? Die sichere Übertragung der Daten durch den Webserver?

Ich glaube, du hast mich wirklich falsch verstanden. Mit Webserver meinte ich einen Rechner außerhalb meines LANs, auf dem verschiedene Dienste wie etwas der Webserver Apache, der Mailserver Postfix und auch ein SSH-Server läuft. Auf diesem Rechner möchte ich mich gerne einloggen.

 

[Terminal]

Ja dann gib mir doch einfach mal die Adresse und ich werde es mal versuchen mich einzuloggen. Name und Passwort wäre nett, dann würde mein Versuch nicht ganz ins Leere gehen.

Dann kann ich dir vielleicht sagen woran es liegt.

 

[anawak12]

Ja dann gib mir doch einfach mal die Adresse und ich werde es mal versuchen mich einzuloggen. Name und Passwort wäre nett, dann würde mein Versuch nicht ganz ins Leere gehen.

Möchtest du vielleicht noch meine Kontonummer, Kennwort und TAN-Liste haben?
Davon ab liegt kein serverseitiges Problem vor. Der Login auf den Server klappt - wie oben beschrieben - mit anderen Clients seit jeher problemlos.

 

[Terminal]

Nein, dein ganzes Bargeld in einem Kuvert wäre auch o.k.

Tja, ich denke dann kann man dir da nicht wirklich weiter helfen. Eine Neuinstallation deiner gesamten Betriebssoftware wird dir ja sicher nicht zusagen? Kann aber am Ende nur die letzte Lösung sein. Und dann einfach mal auf die Applicationen vertrauen die das System schon mitbringt - und nicht gleich was betriebsfremdes installieren.

Vielleicht ist auch einfach nur dein Terminal kaputt, soll ja mal vorkommen. Wenn es per SFTP und FTP-Client klappt, kann man ja nicht vom "Nichtöffnen einer Shell" sprechen. Es wird ja eindeutig eine dabei geöffnet, wenn auch als GUI im FTP-Client Cyberduck. Spielt keine Rolle - ist auch eine Shell.

Also wenn es mir wichtig wäre - System neu installieren - fertig ...

 

[MacMark]

Mach mal mit -vvv, damit gibts mehr Debugmeldungen.

 

[anawak12]

Mach mal mit -vvv, damit gibts mehr Debugmeldungen.

Schon probiert, hier das Resultat.:

OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005
debug1: Reading configuration data /sw/etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to server [xxx.xxx.xxx.xxx] port 2222.
debug1: Connection established.
debug1: identity file /Users/anawak/.ssh/identity type -1
debug3: Not a RSA1 key file /Users/anawak/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/anawak/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /Users/anawak/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/anawak/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 523/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/anawak/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /Users/anawak/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'server' is known and matches the RSA host key.
debug1: Found key in /Users/anawak/.ssh/known_hosts:1
debug2: bits set: 540/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/anawak/.ssh/identity (0x0)
debug2: key: /Users/anawak/.ssh/id_rsa (0x406c60)
debug2: key: /Users/anawak/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/anawak/.ssh/identity
debug3: no such identity: /Users/anawak/.ssh/identity
debug1: Offering public key: /Users/anawak/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp 4e:9d:8f:6f:3c:dc:c3:8d:24:92:5c:6b:c6:c6:2f:7b
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 25
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 17 20
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 0
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 1
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

Ich verstehe einfach nicht, warum OpenSSH keine Shell lädt. Port Forwarding klappt übrigens auch reibungslos. Mir fehlt wirklich ein Ansatz.

Alles Gute
anawak

 

[MacMark]

Hast Du es schon mit
/usr/bin/ssh
probiert?

 

[anawak12]

Hast Du es schon mit
/usr/bin/ssh
probiert?

Ja, das gleiche Problem.

 

[julez_rocca]

Moin, 'n paar Ideen:

Hast Du es mal mit Password-Authentication statt Pub-Key probiert,
nur um sicherzustellen, das ein Connect prinzipiell funktioniert?

Wenn ja, liegt das Problem vielleicht eher Server-seitig (Was akzeptiert der Server, dsa, rsa?)
Oder die Keys stimmen nicht/sind kaputt.

Wie hast Du dein Keys generiert? Zeig bitte mal ein "ls -la" von /Users/anawak/.ssh/.
Da sollten nur id_dsa, id_dsa.pub, id_rsa, id_rsa.pub und known_hosts liegen.

Irgendwo taucht bei Dir PEM auf. Hast Du die Keys im .pem Format? (tut eigentlich nich not)

Ich verbinde mich mit "ssh -pXXX [email protected]" auf meine Server, bis zum
PubKey-Offering sieht ein -vvv ziemlich ähnlich zu deinem Listing aus.

Hast Du an deiner lokalen ssh_config geschraubt? (Ist bei mir komplett auskommentiert.)

debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600

Vielleicht auch ein Netzwerk-Problem? -Schaut arg dünn aus.

Nur so als Denkanstoss.

lg Jules

 

[Hilarious]

Nebenfrage: Bist Du sicher, dass für den Account auf Deinem Server eine Shell definiert ist, und nicht /sbin/nologin oder /bin/badsh? Um was für einen Server handelt es sich?

 

[anawak12]

Nebenfrage: Bist Du sicher, dass für den Account auf Deinem Server eine Shell definiert ist, und nicht /sbin/nologin oder /bin/badsh? Um was für einen Server handelt es sich?

Ja, in /etc/passwd ist für den Account bin/bash eingetragen. Bei dem Server handelt es sich um eine Suse 10, mit Der Login funktioniert ja auch schon seit Monaten von anderen Rechnern aus ohne Probleme.

Auf dem Server läuft OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004


mit folgender sshd_config

Port 22 #durch Firewall von außen über 2222 erreichbar
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTH
LogLevel Info
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 3
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
UsePAM no
AllowTcpForwarding yes
X11Forwarding yes
PermitUserEnvironment yes
MaxStartups 1
Subsystem       sftp    /usr/lib/ssh/sftp-server
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

(alles andere Default)


Alles Gute
anawak