Member. Kein WebUI, upgarde schlägt fehl

UCS - Univention Corporate Server
#1

Hallo zusammen,

ich habe eine neue Umgebung installiert. Eine UCS-Master udn anschließend einen Member. Beim Master ist alles wie gehabt. Die Installation des Members lief ohne Fehler durch. Allerdings erhalte ich, bei Versuch auf das Webinterface des Members zu gehen die Meldung:

The authentication has failed, please login again.

Das Passwort ist jedoch definitiv richtig. Danach wollte ich einfach per Konsole die aktuellen Updates einspielen (zuvor gleiches auf dem Master ohne Probleme). Dabei erhalte ich:

root@vmhost02:~# univention-upgrade --ignoressh --ignoreterm

Starting univention-upgrade. Current UCS version is 4.2-0 errata125

Checking for local repository:                          none
Checking for package updates:                           none
Checking for app updates:                               none
Checking for release updates:                           found: UCS 4.2-1
Do you want to update to 4.2-1 [Y|n]? Y
                                                                                                                                                                            
Starting update to UCS version 4.2-1                                                                                                                                        
                                                                                                                                                                            
HINT:                                                                                                                                                                       
Please check the release notes carefully BEFORE updating to UCS 4.2-1:                                                                                                      
 English version: https://docs.software-univention.de/release-notes-4.2-1-en.html                                                                                           
 German version:  https://docs.software-univention.de/release-notes-4.2-1-de.html                                                                                           
                                                                                                                                                                            
Please also consider documents of following release updates and                                                                                                             
3rd party components.                                                                                                                                                       
                                                                                                                                                                            
Do you want to continue [Y/n]? Y                                                                                                                                            
                                                                                                                                                                            
Checking for space on /var/cache/apt/archives: OK                                                                                                                           
Checking for space on /boot: OK                                                                                                                                             
Checking for space on /: OK                                                                                                                                                 
Checking for package status: OK
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "/usr/lib/pymodules/python2.7/univention/lib/ucs.py", line 23, in __init__
    self.set(version)
  File "/usr/lib/pymodules/python2.7/univention/lib/ucs.py", line 55, in set
    raise ValueError('string does not match UCS version pattern')
ValueError: string does not match UCS version pattern
WARNING: Your domain controller master is still on version -.
         It is strongly recommended that the domain controller master is
         always the first system to be updated during a release update.
This check can be skipped by setting the UCR
variable update42/ignore_version to yes.
Error: Please check "/var/log/univention/updater.log" for details.
ERROR: update failed. Please check /var/log/univention/updater.log


Was läuft da schief?

Viele Grüße
Sven
#2

Gerde kam mir in den Sinn am Member einfach nochmal den Join aufzurufen. Dabei wird das Problem wohl sichtbar:

root@vmhost02:~# univention-join 
univention-join: joins a computer to an ucs domain
copyright (c) 2001-2017 Univention GmbH, Germany

Enter DC Master Account : Administrator
Enter DC Master Password: 

Search DC Master:                                          done
Check DC Master: 

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  ssh-login for Administrator@tux.stedry.local failed. Maybe you entered a wrong password.
**************************************************************************

Das Passwort von Administrator stimmt wohl nicht. Ich habe mich dabei wohl vertippt und komme nicht auf den Server. Mit root kann ich mich per SSH auf dem Member anmelden. Wenn ich dann allerdings versuche das Passwort von Administrator zu ändern:

root@tux:~# su Administrator
Administrator@tux:/root$ passwd
Current Kerberos password: 
passwd: Fehler beim Ändern des Authentifizierungstoken
passwd: Passwort nicht geändert

möchte er das alte Passwort wissen und das scheint nicht zu stimmen. Kann ich das Passwort noch irgendwie zurücksetzen als root?

#3

Ja, mit Hilfe des Tools udm:

udm users/user modify --dn uid=administrator,cn=users,$(ucr get ldap/base) --set password=MyNewPassword
#4

Bevor ich jetzt einen Fehler mache. Mein Passwort beginnt mit Sonderzeichen und enthält auch einige Sonderzeichen:

_%#$…

Muss ich das Passwort bei dem Aufruf irgendwie in “xxx” oder ‘xxx’ einfassen? Ich hatte in der Vergangenheit hiermit schon ab und an Probleme

#5

Würde ‘xxx’ vorziehen …

Tricky wird es, wenn Du im Passwort schon ein ’ und " benutzt hast. Das sollte man lieber vermeiden :slight_smile:

Wenn Du Dich von einer Windows-Maschine per Putty eingeloggt hast, kommt es hier auch gerne zu CharSet-Problemen.
Das könntest Du allerdings bei Putty einstellen.

#6

Nein diese Zeichen sind nicht drin. Also wenn ich das auf dem Master (Host: tux) aufrufe erhalte ich:

root@tux:~# udm users/user modify --dn uid=administrator,cn=users,$(ucr get ldap/base) --set password='****'
Password has been used before. Please choose a different one.

Rufe ich den Befehl auf dem Member (Host: vmhost02) auf:

root@vmhost02:~# udm users/user modify --dn uid=administrator,cn=users,$(ucr get ldap/base) --set password='****'
Traceback (most recent call last):
  File "/usr/share/univention-directory-manager-tools/univention-cli-server", line 222, in doit
    output = univention.admincli.admin.doit(arglist)
  File "/usr/lib/pymodules/python2.7/univention/admincli/admin.py", line 406, in doit
    out = _doit(arglist)
  File "/usr/lib/pymodules/python2.7/univention/admincli/admin.py", line 534, in _doit
    co = univention.admin.config.config(configRegistry['ldap/master'])
  File "/usr/lib/pymodules/python2.7/univention/admin/config.py", line 40, in __init__
    base = univention.admin.uldap.getBaseDN(host)
  File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 136, in getBaseDN
    result = lo.search_s('', ldap.SCOPE_BASE, 'objectClass=*', ['NamingContexts'])
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 559, in search_s
    return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 918, in search_ext_s
    return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 865, in _apply_method_s
    self.reconnect(self._uri,retry_max=self._retry_max,retry_delay=self._retry_delay)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 839, in reconnect
    raise e
SERVER_DOWN: {'desc': "Can't contact LDAP server"}
#7

Fügen Sie dem Aufruf einfach das hier hinzu, damit einmalig die Prüfung auf die Passworthistorie deaktiviert wird: --set overridePWHistory=1

Der Befehl kann nur auf einem Master oder Backup ausgeführt werden, nicht auf einem Member.

#8

Ok, nun hat der den Befehl auf dem Master angenommen aber auf dem Member meldet das Webinterface nach wie vor:

The authentication has failed, please login again.

Und beim versuch den Join am Member zu wiederholen gibt es nach wie vor:

root@vmhost02:~# univention-join 
univention-join: joins a computer to an ucs domain
copyright (c) 2001-2017 Univention GmbH, Germany

Enter DC Master Account : Administrator
Enter DC Master Password: 

Search DC Master:                                          done
Check DC Master: 

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  ssh-login for Administrator@tux.stedry.local failed. Maybe you entered a wrong password.
**************************************************************************
#9

Was steht denn auf dem Member in /var/log/univention/join.log für den Join-Versuch?

Und was steht auf dem master in /var/log/auth.log zum selben Zeitpunkt?

#10

Master:

root@tux:~# tail -f /var/log/auth.log
Aug 30 08:32:01 tux CRON[28719]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 30 08:32:02 tux CRON[28719]: pam_unix(cron:session): session closed for user root
Aug 30 08:34:01 tux CRON[28738]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 30 08:34:01 tux CRON[28738]: pam_unix(cron:session): session closed for user root
Aug 30 08:35:02 tux CRON[28757]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 30 08:35:02 tux CRON[28757]: pam_unix(cron:session): session closed for user root
Aug 30 08:35:27 tux sshd[28768]: Accepted keyboard-interactive/pam for root from 10.0.11.14 port 54042 ssh2
Aug 30 08:35:27 tux sshd[28768]: pam_unix(sshd:session): session opened for user root by (uid=0)
Aug 30 08:36:01 tux CRON[28786]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 30 08:36:02 tux CRON[28786]: pam_unix(cron:session): session closed for user root

Member:

  remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password).
Tue Aug 29 16:45:57 CEST 2017: finish /usr/sbin/univention-join
Wed Aug 30 08:41:13 CEST 2017: starting /usr/sbin/univention-join 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for tux.stedry.local has changed,
and the key for the corresponding IP address 192.168.1.2
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:3
  remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ECDSA key sent by the remote host is
2b:f7:f7:21:57:f4:67:bb:03:8f:f0:cb:0e:36:77:ba.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
  remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password).
Wed Aug 30 08:41:27 CEST 2017: finish /usr/sbin/univention-join
root@vmhost02:~# ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local
# Host tux.stedry.local found: line 1 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

ok, das dürfte wohl daher rühren dass ich den Master in eine VM verfrachtet habe, oder?

Also habe ich am Member ein:

ssh-keygen -f "/root/.ssh/known_hosts" -R tux.stedry.local

aufgerufen. Es Ändert sich jedoch nichts:

Am Member:

root@vmhost02:~# univention-join 
univention-join: joins a computer to an ucs domain
copyright (c) 2001-2017 Univention GmbH, Germany

Enter DC Master Account : Administrator
Enter DC Master Password: 

Search DC Master:                                          done
Check DC Master: 

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  ssh-login for Administrator@tux.stedry.local failed. Maybe you entered a wrong password.
**************************************************************************

Member-Log:

root@vmhost02:~# tail -f /var/log/univention/join.log
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password).
Wed Aug 30 08:41:27 CEST 2017: finish /usr/sbin/univention-join
Wed Aug 30 08:44:15 CEST 2017: starting /usr/sbin/univention-join 
Warning: Permanently added 'tux.stedry.local' (ECDSA) to the list of known hosts.
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
Wed Aug 30 08:44:35 CEST 2017: finish /usr/sbin/univention-join
Wed Aug 30 08:47:11 CEST 2017: starting /usr/sbin/univention-join 
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
Wed Aug 30 08:47:33 CEST 2017: finish /usr/sbin/univention-join
#11

Und das auth.log vom Master beim letzten Versuch (also nach dem Entfernen des alten SSH-Host-Keys mit ssh-keygen)?

#12

Da taucht lediglich eine Zeile auf und ich weiß nicht ob diese was damit zu tun hat:

Aug 30 09:08:07 tux CRON[30059]: pam_unix(cron:session): session closed for user root
#13

Ein paar Minuten später kam hier noch:

Aug 30 09:11:18 tux nscd: nss_ldap: reconnecting to LDAP server...
Aug 30 09:11:18 tux nscd: nss_ldap: reconnected to LDAP server ldap://tux.stedry.local:7389 after 1 attempt

ich weiß nicht ob es was damit zu tun hat

#14

Bitte posten Sie die Ausgabe der folgenden Befehle:

Auf dem Master:

host tux.stedry.local

Auf dem Member:

host tux.stedry.local
ssh -v administrator@tux.stedry.local
#15 
root@tux:~# host tux.stedry.local
tux.stedry.local has address 192.168.1.2

Das ist doch falsch. Der tux (Master) hat die 192.168.1.5

nano /etc/network/interfaces

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 192.168.1.5
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1

nano /etc/hosts

127.0.0.1       localhost
192.168.1.5     tux.stedry.local tux

::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

root@vmhost02:~# host tux.stedry.local
tux.stedry.local has address 192.168.1.2

root@vmhost02:~# ssh -v administrator@tux.stedry.local
OpenSSH_6.7p1 Debian-5+deb8u3A~4.2.0.201702101826, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 28: Applying options for *
debug1: Connecting to tux.stedry.local [192.168.1.2] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3A~4.2.0.201702101826
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 2b:f7:f7:21:57:f4:67:bb:03:8f:f0:cb:0e:36:77:ba
debug1: Host 'tux.stedry.local' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
administrator@tux.stedry.local's password:

Das dürfte das Problem sein aber woher kommt die falsche IP?

#16

Wenn ich’s richtig sehe:

  • Ihr Master heißt tux und hat die 192.168.1.5
  • Ihr Member heißt vmhost02 und hat die 192.168.1.2

Richtig?

Was enthält denn die /etc/hosts auf dem Member, und was ist die Ausgabe von ucr search --brief nameserver (auch auf dem Member)?

#17

Ja

Nein, der vmhost02 hat die 192.168.1.10

127.0.0.1       localhost
192.168.1.10    vmhost02.stedry.local vmhost02

::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

root@vmhost02:~# ucr search --brief nameserver 
nameserver/external: <empty>
nameserver/option/timeout: 2
nameserver1: 192.168.1.1
nameserver2: 192.168.1.5
nameserver3: 192.168.1.22

Das kommt noch von der Installation:

  • die 1.1 ist der Router (Default-GW) damit ich internet während der Installation habe
  • die 1.5 ist der Master
  • die 1.22 ist der Win2012 ADS an den der Master (nun im dortigen Netz) mittes Connector verbunden werden soll
#18

Alrighty. Dann bitte noch die Ausgabe hiervon vom Member:

host tux.stedry.local 192.168.1.1
host tux.stedry.local 192.168.1.5
host tux.stedry.local 192.168.1.22
#19 
root@vmhost02:~# host tux.stedry.local 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases: 

Host tux.stedry.local not found: 3(NXDOMAIN)

root@vmhost02:~# host tux.stedry.local 192.168.1.5
Using domain server:
Name: 192.168.1.5
Address: 192.168.1.5#53
Aliases: 

tux.stedry.local has address 192.168.1.2

root@vmhost02:~# host tux.stedry.local 192.168.1.22
Using domain server:
Name: 192.168.1.22
Address: 192.168.1.22#53
Aliases: 

Host tux.stedry.local not found: 3(NXDOMAIN)
#20

Auf dem Master ist der DNS-Eintrag für den Host falsch. Sollte natürlich nicht sein. Loggen Sie sich mal in der Univention Management Console ein, navigieren Sie zu »Domäne« → »DNS« dann links im Baum sterdy.local anklicken, rechts in der Liste den Eintrag für tux bearbeiten. Dann die IP-Adresse auf 192.168.1.5 korrigieren, speichern. Kurz warten. Anschließend auf dem Member mit host tux.sterdy.local 192.168.1.5 kontrollieren, dass dort auch tux.sterdy.local has address 192.168.1.5 herauskommt.

Klappt das? Dann muss noch einmal mit ssh-keygen der Eintrag für tux.sterdy.local entfernt werden, da momentan noch der Key des falschen Servers gespeichert sein dürfte. Zu guter Letzt sollte dann auch ein ssh administrator@tux.sterdy.local funktionieren und auch ein univention-join. Evtl. ein Reboot vom Member vor dem ssh-Versuch, damit es kein Caching gibt.

Mastodon