leap: ssh-login von debian 6.0.4
Hi, bei mir läuft noch ein altes debian-System als Doku-Server (archivista). Seit mein Server auf leap 42.1 aufgerüstet wurde, klappt der ssh-login (für rsync) vom Client aus nicht mehr. Die Verbindung wird vom debian-client abgebrochen. Das Server-Log sagt nucr Verbindung vom Client abgebrochen. Der Client : ssh -v archivista@192.168.70.1 OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.70.1 [192.168.70.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 '192.168.70.1' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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: /root/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 Last login: Thu Apr 28 00:30:08 2016 from avlinux64 Have a lot of fun... 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 debug1: channel 0: free: client-session, nchannels 1 Connection to 192.168.70.1 closed. Transferred: sent 2840, received 3528 bytes, in 0.1 seconds Bytes per second: sent 43911.8, received 54549.6 debug1: Exit status 1 Vermutlich wurde in der sshd-Config auf dem Server was verstellt, aber was ? Weiss jemand Rat ? mfg K. Müller
2016-04-28 0:38 GMT+02:00 Kasimir Müller <Kasimir.Mueller@t-online.de>:
Die Verbindung wird vom debian-client abgebrochen. Das Server-Log sagt nucr Verbindung vom Client abgebrochen.
Dann halt mal Logging auf Debug stellen. man sshd_config
debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1
dsa-Keys wurden abgeschaltet. Bau Dir einen rsa-Key oder schalte sie beim Server an. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Thu, 28 Apr 2016 00:38:36 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
Hi,
bei mir läuft noch ein altes debian-System als Doku-Server (archivista). Seit mein Server auf leap 42.1 aufgerüstet wurde, klappt der ssh-login (für rsync) vom Client aus nicht mehr. Die Verbindung wird vom debian-client abgebrochen. Das Server-Log sagt nucr Verbindung vom Client abgebrochen. Der Client :
ssh -v archivista@192.168.70.1
OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.70.1 [192.168.70.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 '192.168.70.1' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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: /root/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 Last login: Thu Apr 28 00:30:08 2016 from avlinux64 Have a lot of fun... 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 debug1: channel 0: free: client-session, nchannels 1 Connection to 192.168.70.1 closed. Transferred: sent 2840, received 3528 bytes, in 0.1 seconds Bytes per second: sent 43911.8, received 54549.6 debug1: Exit status 1
Vermutlich wurde in der sshd-Config auf dem Server was verstellt, aber was ? Weiss jemand Rat ?
Ist in einer der ssh_config das Login für root disabled? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht! Hier noch die Configs: ssh_config auf dem Client mit debian: Host * # ForwardAgent no # ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # GSSAPIKeyExchange no # GSSAPITrustDNS no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com SendEnv LANG LC_* HashKnownHosts yes # GSSAPIAuthentication no GSSAPIDelegateCredentials no Protocol 2 sshd_config auf dem Server mit Leap: #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # The default requires explicit activation of protocol 1 #Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Ciphers and keying #RekeyLimit default none # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #RSAAuthentication yes #PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable support for the deprecated 'gssapi' authentication # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included # in this release. The use of 'gssapi' is deprecated due to the presence of # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to. #GSSAPIEnableMITMAttack no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation sandbox # Default for new installations. #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/lib/ssh/sftp-server # This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5). 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 # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server mfg K.Müller
Am Thu, 28 Apr 2016 10:03:24 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht!
Hier noch die Configs: [...] sshd_config auf dem Server mit Leap: [..] #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
Da steht es doch, PermitRootLogin ist auskommentiert, der Defaultwert ist 'no'. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 04/28/2016 10:59 AM, Dieter Klünter wrote:
Am Thu, 28 Apr 2016 10:03:24 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht!
Hier noch die Configs: [...] sshd_config auf dem Server mit Leap: [..] #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 Da steht es doch, PermitRootLogin ist auskommentiert, der Defaultwert ist 'no'.
-Dieter
man sshd_config PermitRootLogin Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or “no”. The default is “yes”. Grüße, Kai
Am 28.04.2016 um 10:59 schrieb Dieter Klünter:
Am Thu, 28 Apr 2016 10:03:24 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht!
Hier noch die Configs: [...] sshd_config auf dem Server mit Leap: [..] #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 Da steht es doch, PermitRootLogin ist auskommentiert, der Defaultwert ist 'no'.
-Dieter
Ich möchte auch nicht als root sondern als vorhandener Benutzer einloggen. Von einem x-beliebigen anderen System geht es auch. mfg K. Müller
Am Thu, 28 Apr 2016 11:22:19 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
Am 28.04.2016 um 10:59 schrieb Dieter Klünter:
Am Thu, 28 Apr 2016 10:03:24 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht!
Hier noch die Configs: [...] sshd_config auf dem Server mit Leap: [..] #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 Da steht es doch, PermitRootLogin ist auskommentiert, der Defaultwert ist 'no'.
-Dieter
Ich möchte auch nicht als root sondern als vorhandener Benutzer einloggen. Von einem x-beliebigen anderen System geht es auch.
In dem debug Output hast du dich aber als root versucht einzuloggen. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 28.04.2016 um 12:02 schrieb Dieter Klünter:
Am Thu, 28 Apr 2016 11:22:19 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
Am 28.04.2016 um 10:59 schrieb Dieter Klünter:
Am Thu, 28 Apr 2016 10:03:24 +0200 schrieb Kasimir Müller <Kasimir.Mueller@t-online.de>:
P.S.: der Login zu einer Suse 13.1 funktioniert, auch der Login zu einer jungfräulichen Installation von Leap funktioniert nicht!
Hier noch die Configs: [...] sshd_config auf dem Server mit Leap: [..] #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 Da steht es doch, PermitRootLogin ist auskommentiert, der Defaultwert ist 'no'.
-Dieter
Ich möchte auch nicht als root sondern als vorhandener Benutzer einloggen. Von einem x-beliebigen anderen System geht es auch. In dem debug Output hast du dich aber als root versucht einzuloggen.
-Dieter
Stimmt nicht. Ich habe mich als archivista beim Server von einem root-account auf dem Client versucht anzumelden. Sicherheitshalber habe ich es auch von einem anderen account aus versucht, das geht auch nicht. Das ssh-login vom Client auf einen anderen Rechner mit openSuse 13.1 geht. Deshalb muss es wohl an der Kombination Client-Config in ssh_config under Server-Config in sshd_config liegen, aber was ? mfg K. Müller
Hi, das Problem sass wohl doch vor dem Computer. Schuld war das .Xauthority auf dem Server. Ich kam darauf, als ssh -a -x funktionierte. Ich habe dann das .Xauthority gelöscht und es wurde beim nächsten login automatisch wiedererstellt. Danke an alle für Eure Bemühungen. mfg K. Müller
participants (4)
-
Dieter Klünter
-
Kai Grunau
-
Kasimir Müller
-
Martin Schröder