Debian 8.2 Loginfehler SSH Secure Shell Client

M

motte

Member
Hallo Leute

Ich habe mir einen Vserver von Hetzner besorgt und dort Debian 8.2 LAMP ( LAMP-Image: Basis-System mit SSH-Dienst und weiteren Diensten, Werkzeugen und Bibliotheken (z.B. Apache, MySQL, PHP, Perl, Webmin, OpenSSL, FTP) )
Installiert .

Mit Putty kann ich mich Problemlos einloggen aber nicht mit SSH Secure Shell Client da kommt dann der folgende Fehler siehe Foto

Kann mir einer sagen an was das liegt?:confused::confused:

MFG Motte
 

Attachments

  • ssh.JPG
    ssh.JPG
    22.2 KB · Views: 149
Client und Server können sich nicht auf ein "Verschlüsselungsverfahren" einigen. Schau mal nach Ciphers, MACs und KexAlgorithms in /etc/ssh/ssh_config auf dem Client und /etc/ssh/sshd_config auf dem Server.

--
.A.
 
/etc/ssh/sshd config

Code: 
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# 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
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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

Client :

Code: 
## SSH CONFIGURATION FILE FORMAT VERSION 1.1
## REGEX-SYNTAX egrep
## end of metaconfig
## (leave above lines intact!)
## ssh2_config
## SSH 3.2 Windows Command Line Client Configuration File
##
## Affects also sftp2.exe and scp2.exe which use ssh2.exe for transport.
##
## This file should be located in <USERPROFILE>\Application Data\SSH.
## (Run ssh2.exe -h, it displays the full path.)
##
## The ".*" is used for all hosts, but you can use other hosts as
## well. See examples at the end of the file.
.*:

## General

#	VerboseMode			no
#	QuietMode			no
#	BatchMode			no
#	Compression			no
#	ForcePTTYAllocation		no
#	EscapeChar			~
#	PasswordPrompt			"%U@%H's password: "
#	PasswordPrompt			"%U's password: "
#	AuthenticationSuccessMsg	yes
#       SetRemoteEnv                    FOOBAR=baz

## Network

#	Port				22
#	NoDelay				no
#	KeepAlive			yes
#	SocksServer			socks://fw.company.com:1080/10.1.0.0/16,127.0.0.1/8
#	SocksServer			socks://mylogin@socks.ssh.com:1080/203.123.0.0/16,198.74.23.0/24
#	UseSocks5			no

## Crypto

#	Ciphers				aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc 
#	MACs				hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#	StrictHostKeyChecking           ask	
#	RekeyIntervalSeconds		3600

## User public key authentication

#	IdentityFile			identification
#	RandomSeedFile			RandomSeed

## External key provider

#	EkProvider			pkcs11
#	EkInitString			dll(token_vendor_pkcs11v2.10.dll)
#	EkInitString			dll(vendorpkcs11.dll) slots(1)

## Server certificate authentication

#	HostCANoCRLs			"CACertificates/test-ca-certificate.cer"
#	HostCA				"CACertificates/ca-certificate.cer"
#	LdapServers			ldap://server.domain-name:389
#	DefaultDomain			foobar.com

## Tunneling

#	GatewayPorts			no
#	ForwardAgent			yes
#	ForwardX11			no

# Tunnels that are set up upon login
#
#      LocalForward                    "110:pop3.company.com:110"
#      LocalForward                    "143:imap.company.com:143"
#      LocalForward                    "25:smtp.company.com:25"
#      RemoteForward                   "3000:localhost:22"

## SSH1 Compatibility

#	Ssh1InternalEmulation		yes
#	Ssh1MaskPasswordLength		yes

## Authentication 
## publickey, keyboard-interactive and password allowed by default
## Least interactive method should be usually attempted first.

#	AllowedAuthentications		publickey,keyboard-interactive,password

## Examples of per host configurations

#alpha.*:
#	Host				alpha.oof.fi
#	User				username_at_alpha
#	PasswordPrompt			"%U:s password at %H: "
#	Ciphers				aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

#foobar:
#	Host				foo.bar
#	User				foo_user
 
welche Version des "SSH Secure Shell Client" verwendest Du denn? Die letzte freie, die man für nicht-kommerziellen Einsatz kostenlos herunterladen konnte ist schon "ein wenig" älter und sicherlich nichts, was man heute von der Aktualität her noch einsetzen möchte.
 
Dein Client ist hoffnungslos veraltet, bitte schleunigst zu Grabe tragen.


Dein Server möchte hingegen aus dem Bälleparadies abgeholt werden:
RSAAuthentication, X11Forwarding und UsePAM bitte auf no setzen.
 
Joe User said:
RSAAuthentication, X11Forwarding und UsePAM bitte auf no setzen.
Click to expand...

RSAAuthentication gilt nur, wenn Protokoll-Version 1 genutzt wird. Wegen
Code: 
Protocol 2
kannst Du bei RSAAuthentication einen beliebigen Wert setzen.

X11Forwarding zu deaktivieren bringt so richtig nur was, wenn auch das gesamte port forwarding deaktiviert wird. Sonst ist der Gewinn eher gering.

Und UsePAM zu deaktivieren kann, je nach weiterer Konfiguration des Systems, auch Sicherheit kosten.

--
.A.
 
Bzgl. UsePAM wollte ich auch schreiben, dass es durchaus seine Berechtigung hat. Kommt halt auch immer auf den Einsatzzweck an.

Gruß
Markus
 
PAM will man generell nicht wirklich nutzen wie das Zitat am Ende dieses Blogpost passend zusammenfasst:
http://bsdly.blogspot.ca/2015/07/the-openssh-bug-that-wasnt.html
Der Blogpost als Ganzes zeigt beispielhaft warum "UsePAM yes" pöse ist und generell auf no gesetzt werden sollte. Ebenso zeigt der Blogpost auch, warum UsePAM nicht per Default auf no steht:
Die OpenBSD/OpenSSH-Devs entwickeln primär für OpenBSD welches ohne PAM daherkommt und wie es schon immer typisch für OpenBSD-Devs (insbesondere Theo) war und ist, geht ihnen die Sicherheit anderer Systeme genüsslich am Arsch vorbei.
 
You must log in or register to reply here.
Back
Top