SSH tcsh Problem

[doll1]

Hallo Gemeinde, Hallo Joe,

nach meinem letzten Systemupdate habe ich das Problem, dass ich es nicht mehr schaffe, mich an meinem FreeBSD Server anzumelden. Alles was ich bekomme, ist folgendes:

Code: Select all

ford@HerzausGold:~$ ssh admin@doll1.org
Last login: Wed Apr 24 08:35:54 2013 from dsdf-4d0a11e5.pool.mediaways.net
FreeBSD 9.1-RELEASE (GENERIC) #0: Wed Jan  2 19:41:22 CET 2013

Welcome to doll1.org!

/bin/tcsh: Undefined symbol "libiconv_open"
Connection to doll1.org closed.

Sagt mir bitte, dass es eine Möglichkeit gibt, da wieder rein zu kommen. :-??

Und, für den Fall dass nicht (es ist ein Test- und Lern-System), würd ich gern diskutieren, wie man so etwas vermeiden kann.

Beste Grüße
doll1

[doll1]

Ach ja, sftp connected auch nicht

Code: Select all

ford@HerzausGold:~$ sftp admin@doll1.org
Connection closed

[ddm3ve]

ssh -vvv user@....

Damit erhälst Du detailliert, was schief bzw. was beim connect ab läuft.
Und ich würde vermuten, dass die ssh Konfiguration sich geändert hat also damit ggf. die ssh Keys nicht mehr angezogen werden.

[doll1]

Code: Select all

ford@HerzausGold:~$ ssh -vvv admin@doll1.org
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to doll1.org [85.25.118.145] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/ford/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/ford/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/ford/.ssh/id_rsa-cert type -1
debug1: identity file /home/ford/.ssh/id_dsa type -1
debug1: identity file /home/ford/.ssh/id_dsa-cert type -1
debug1: identity file /home/ford/.ssh/id_ecdsa type -1
debug1: identity file /home/ford/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "doll1.org" from file "/home/ford/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/ford/.ssh/known_hosts:3
debug3: load_hostkeys: found key type RSA in file /home/ford/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 2 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 21:0f:db:58:2c:d2:46:a0:fe:85:c9:b9:3d:99:b8:a6
debug3: load_hostkeys: loading entries for host "doll1.org" from file "/home/ford/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/ford/.ssh/known_hosts:3
debug3: load_hostkeys: found key type RSA in file /home/ford/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 2 keys
debug3: load_hostkeys: loading entries for host "85.25.118.145" from file "/home/ford/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/ford/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'doll1.org' is known and matches the ECDSA host key.
debug1: Found key in /home/ford/.ssh/known_hosts:3
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ford/.ssh/id_rsa (0x7f6e96cb8bd0)
debug2: key: /home/ford/.ssh/id_dsa ((nil))
debug2: key: /home/ford/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,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: Offering RSA public key: /home/ford/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp bb:4a:c5:1e:22:91:36:93:da:e5:96:7d:1c:df:09:3d
debug3: sign_and_send_pubkey: RSA bb:4a:c5:1e:22:91:36:93:da:e5:96:7d:1c:df:09:3d
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to doll1.org ([85.25.118.145]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 65536
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Apr 24 09:32:52 2013 from dsdf-4d0a11e5.pool.mediaways.net
FreeBSD 9.1-RELEASE (GENERIC) #0: Wed Jan  2 19:41:22 CET 2013

Welcome to doll1.org!

/bin/tcsh: Undefined symbol "libiconv_open"
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Connection to doll1.org closed.
Transferred: sent 2984, received 2048 bytes, in 0.2 seconds
Bytes per second: sent 14731.5, received 10110.6
debug1: Exit status 1

was meinst Du mit, die keys werden eventuell nicht mehr 'angezogen'? Hab jetzt auf die schnelle nicht rausgekriegt, wie man es im code-tag hervorhebt, aber ich sehe da mittendrin deutlich ein

debug1: Authentication succeeded (publickey).
Authenticated to doll1.org ([85.25.118.145]:22).
:-\

[Joe User]

Definiere bitte "Systemupdate", denn Dein Kernel hat noch kein Update erfahren und mein SSHd meldet sich auch anders:

Code: Select all

OpenSSH_5.8p2 FreeBSD-20110503, OpenSSL 0.9.8x 10 May 2012

Da scheint beim "Systemupdate" etwas ganz übel schiefgegangen zu sein. Wie hast Du das Systemupdate durchgeführt?


EDIT: Sorry, im Debugmode meldet sich auch mein SSHd so wie Deiner, also ignoriere einfach diesen Teil des Posts.

[doll1]

Naja :-?
Ich gebe zu, dass ich derzeit nicht gerade täglich auf dem Server bin/war.
Soll heißen, wenn ich jetzt drauf wär, könnte ich dir genauer sagen, was ich da gemacht habe. :oops:
Hauptsächlich war es wohl ein:

freebsd-update fetch
freebsd-update install

Die meisten anderen Services (was per http/s so erreichbar ist) scheinen noch zu laufen.

[Joe User]

Reboot schon versucht? Alternativ per manuellem Update gemäss FreeBSD-Handbuch versucht?

[doll1]

Reboot hört sich erstmal nach einer guten Idee an, auch wenn es kein Wind*ws ist =))

Manuell kann ich da ja grad garnichts machen.

Ich bin mir inzwischen übrigens fast sicher, dass ich auch nach diesem Update schonmal 'drauf' war. Um im Web-Space ein laravel Framework zu installieren. :-ss

[doll1]

Hm,

nach dem reboot :-?

Die SSH Server Antwort bleibt die gleiche.

Neu ist: Der Apache spricht nicht mehr mit meinem Browser. :|

Ich denke nicht, dass ich das Ganze mit einer rhytmischen ping-attacke (ein Service der noch funktioniert) wieder gerade gedengelt krieg. :-B

Da ist es jetzt wohl eher an der Zeit, tief durch zu atmen, zwei Kannen Kaffee zu kochen und sich während der Neuinstallation Gedanken über Best-Practices zur Vermeidung solcher Situationen zu machen. ](*,)

Oder hat noch jemand einen Vorschlag?

[Joe User]

Ich kann Dir nur mitteilen, dass ich persönlich Updates des Basissystems generell per "make [build|install][world|kernel]" durchführe.
"freebsd-update" habe ich noch nie genutzt, liegt aber daran, dass ich meine Systeme gerne schlank und ressourcenschonend halte und deshalb mit angepassten Optionen selbstkompiliere. "freebsd-update" liefert hingegen nur von FreeBSD vorkompilierte Updates, welche auf selbstkompilierten Systemen Probleme bereiten können.
Andererseits ist selbstkompilieren zeitaufwändig und je nach Hardware auch von der Last nicht zu unterschätzen.

Eine Empfehlung für das Eine oder Andere ist also etwas schwierig ;)

[ddm3ve]

Ist die tcsh "normal"?

Ich würde, als Linux User, ein csh, ssh oder bash als Login shell erwarten.
Muss aber an der Stelle auch zugeben, dass ich keine tieferen BSD Kenntnisse besitze.
Meine Vermutung lag darin, dass eventuell die ssh_config überschrieben wurde. Hat sich geklärt die Anmeldung selbst funktioniert erstmal bei der Legitimierung.

Mein Tipp an der Stelle, ein Refernzsystem auf bauen, und geziehlt dieses erst testen, danach am Lifesystem durch führen.

[Joe User]

Die Standard-Shell bei FreeBSD ist /bin/sh (basiert auf der Original http://en.wikipedia.org/wiki/Almquist_shell).

/bin/csh (http://en.wikipedia.org/wiki/C_shell) und die darauf basierte /bin/tcsh (http://en.wikipedia.org/wiki/Tcsh) sind beiden Alternativen welche FreeBSD von Haus aus mitbringt. Allerdings fungiert /bin/tcsh unter FreeBSD als Default-Login-Shell für den root-User, während normale User /bin/sh als Default-Login-Shell haben.

bash und andere Shells lassen sich problemlos als Port installieren und per chpass einzelnen Usern als Default-Shell zuweisen:

Code: Select all

chpass -s /usr/local/bin/bash username

Für root würde ich das nicht machen, aber für Deine User ist das eventuell hilfreich.
Bei Scripts würde ich hingegen einfach nur die Shebang entsprechend setzen, macht am Wenigsten Probleme.
Wenn möglich, sollten Scripts aber so umgeschrieben werden, dass sie mit /bin/sh kompatibel sind.

[Joe User]

@doll1
Deine libiconv aus dem Basissystem scheint nicht mehr zu Teilen vom restlichen Basissystem zu passen.
Warum das so ist, erschliesst sich mir im Moment leider nicht wirklich. Vielleicht ein fehlerhaftes oder unvollständiges freebsd-update, vielleicht ein Fehler beim Vorkompilieren seitens FreeBSD, vielleicht auch irgendein blöder Fehler in Deinem System, ich weiss es leider nicht.

Sicher ist nur, dass Deine libiconv nicht mehr zu Teilen vom Basissystem passt, oder umgekehrt.

Zu beheben ist das Problem wahrscheinlich nur durch ein vollständiges (manuelles) Systemupdate/downdate per Rescuesystem.

[daemotron]

Bestätigung; hier handelt es sich um ein Link-Problem (und wahrscheinlich beim Apachen und allen anderen nachinstallierten Programmen auch).

Reparaturmöglichkeit besteht, bedarf aber eines FreeBSD-basierten Rettungssystems (oder alternativ einmal von der Live-DVD booten).

Prinzipielle Vorgehensweise:

• Ins Rettungssystem booten
• Festplatte(n) mounten
• ggf. Subversion im Rettungssystem installieren (falls dort nicht vorhanden)
• /mnt/usr/src per SVN auf den neuesten Stand bringen (Du willst vermutlich base/releng/9.1/)
• /mnt/usr/obj leeren
• mergemaster -m /mnt/usr/src -D /mnt -piU
• make buildworld und make buildkernel (in /mnt/src) laufen lassen
• make installkernel und make installworld jeweils mit DESTDIR=/mnt ausführen
• /dev nach /mnt/dev mounten
• chroot /mnt /bin/tcsh und hoffen, dass es funktioniert...
• Danach: Ports-Sourcen (/usr/ports) auf den neuesten Stand bringen
• Liste der installierten Ports erzeugen (z. B. mit portmaster)
• Alle Ports/Packages löschen
• Alle benötigten Ports/Packages neu installieren

Wie gesagt, dass ist die prinzipielle Vorgehensweise; nicht jedes einzutippende Kommando ist hier aufgeführt. Dazu bitte auf die entsprechende Doku zurückgreifen, insbesondere:

http://www.freebsd.org/doc/en_US.ISO885 ... k/svn.html
http://www.freebsd.org/doc/en_US.ISO885 ... ading.html