SSH mit Key absichern

[lugau45]

Hallo, ich habe jetzt die NAS 1019+ im Einsatz. Wie kann ich denn den SSH Zugang mit Key absichern. Alles Infos aus dem Netz habe ich durch.
authorized_keys angelegt chmod 0600
in der /etc/ssh/sshd_config ist
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Es wird aber kein Key genutzt:

ssh -v admin@192.168.178.100                    
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/marco/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.178.100 [192.168.178.100] port 22.
debug1: Connection established.
debug1: identity file /home/marco/.ssh/id_rsa type 0
debug1: identity file /home/marco/.ssh/id_rsa-cert type -1
debug1: identity file /home/marco/.ssh/id_dsa type -1
debug1: identity file /home/marco/.ssh/id_dsa-cert type -1
debug1: identity file /home/marco/.ssh/id_ecdsa type -1
debug1: identity file /home/marco/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/marco/.ssh/id_ed25519 type -1
debug1: identity file /home/marco/.ssh/id_ed25519-cert type -1
debug1: identity file /home/marco/.ssh/id_xmss type -1
debug1: identity file /home/marco/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 192.168.178.100:22 as 'admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:D50wiMBreh7fxS5rS2sY4+Xn3Qhgls7wtGciItA4VAg
debug1: Host '192.168.178.100' is known and matches the RSA host key.
debug1: Found key in /home/marco/.ssh/known_hosts:201
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/marco/.ssh/id_rsa RSA SHA256:TFmMncMPKkxLP3AC8yFDhjKvhdRTItk4i0XctKIiafI
debug1: Will attempt key: /home/marco/.ssh/id_dsa 
debug1: Will attempt key: /home/marco/.ssh/id_ecdsa 
debug1: Will attempt key: /home/marco/.ssh/id_ed25519 
debug1: Will attempt key: /home/marco/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/marco/.ssh/id_rsa RSA SHA256:TFmMncMPKkxLP3AC8yFDhjKvhdRTItk4i0XctKIiafI
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/marco/.ssh/id_dsa
debug1: Trying private key: /home/marco/.ssh/id_ecdsa
debug1: Trying private key: /home/marco/.ssh/id_ed25519
debug1: Trying private key: /home/marco/.ssh/id_xmss
debug1: Next authentication method: password
admin@192.168.178.100's password:

Hat jemand noch eine Idee?

 

[Fusion]

Was hast du genau auf dem Server und was auf dem Client eingerichtet?

Wie sieht die /etc/ssh/sshd_config auf dem NAS aus, wie die /etc/ssh/ssh_config auf dem Client?
Öffentliche (nas) und private (client) Schlüssel richtig verteilt?

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/marco/.ssh/id_rsa RSA SHA256:TFmMncMPKkxLP3AC8yFDhjKvhdRTItk4i0XctKIiafI
debug1: Authentications that can continue: publickey,password

da sollte nicht "offering public key" sondern "trying private key" stehen, wenn alles andere richtig ist.

 

[lugau45]

Also die /etc/ssh/sshd_config vom NAS:

cat /etc/ssh/sshd_config     
Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
#       $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#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

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#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
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# 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 yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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 no
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/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/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
Match User root
        AllowTcpForwarding yes
Match User admin
        AllowTcpForwarding yes
Match User anonymous
        AllowTcpForwarding no
        GatewayPorts no

Der Client ist richtig eingerichtet da ich damit ohne Probleme auf andere Server per Key zugriff habe. Ich vermute es liegt an der Config vom NAS.

 

[Fusion]

Dann hast du doch schon eine gute Ausgangslage und kannst die Verbindung mit den anderen vergleichen.

Zu den anderen Servern benutzt du auch dasselbe Schlüsselpaar? Oder wie hast du die Schlüssel auf dem Client organisiert in ~/.ssh/

Edit:
Und wo ist der public key genau eingetragen? Eventuell in /root/.ssh/authorizedkeys ?
Kannst dich mit ssh root@nas einloggen?

 

[lugau45]

Naja die config auf einem Debian Server ist eben nicht genau gleich. Ja ich nutze den selben Schlüssel. Der public Key ist in /admin/.ssh/authorized_keys. Der Benutzer ist auch admin.
admin@ip klappt mit dem Passwort ohne Probleme.

 

[Fusion]

Probier es erst mal mit root und pack den key unter /root/.ssh/authorizedkeys auf dem NAS.

Den Pfad /admin gibt es auf dem NAS nicht.

Hast du den Benutzer "admin" selbst bei der ersten Installation angelegt?
Weil Synology legt selbst schon einen Benutzer mit exakt diesem Namen an und deaktiviert diesen Nutzer.
Der Home Ordner von admin liegt unter /var/services/homes/admin/

 

[lugau45]

Ja hatte ich angelegt. Naja ich abe es nun bei root auch drin kommt aber auch pw wenn ich verbinden möchte.

 

[ThomasK]

SSH als root ist bei den Synology Geräten gesperrt. Zur Freischaltung in /etc/ssh/sshd_config editieren: PermitRootLogin yes

 

[Tommes]

SSH als root ist bei den Synology Geräten gesperrt.

Das ist so nicht ganz richtig. Gesperrt ist der Login per root nur, wenn man versucht, sich direkt (ohne Key) aufzuschalten. Hier führt der Weg erst über den admin um anschließend per sudo -i root Rechte zu erhalten. Hier muss man, um das Verhalten zu ändern, wie du richtig erwähnt hast, die etc/ssh/sshd_config editieren um sich direkt als root aufschalten zu können. Mittels RSA-Key ist das aber hinfällig, das die Verbindung per Key auch ohne Anpassung der o.a. Datei funktioniert. Ich mach das seit eh und je so, und habe noch die etc/ssh/sshd_config angepackt.

Tommes

 

[framp]

... Das ist so nicht ganz richtig. Gesperrt ist der Login per root nur, wenn man versucht, sich direkt (ohne Key) aufzuschalten. ... Mittels RSA-Key ist das aber hinfällig, das die Verbindung per Key auch ohne Anpassung der o.a. Datei funktioniert.

Kann ich nur bestaetigen. Bislang habe ich mich auch erst als neuer admin (Ich benutze nicht admin sondern habe einen anderen Benutzernamen als admin konfiguriert) angemeldet und dann per sudo root Rechte erhalten. Nachdem ich diesen Thread gelesen habe habe ich nur die authorized_keys vom neuen admin in /root/.ssh kopiert und ohne PermiteRootLoginYes kann ich mich sofort als root anmelden.

Bin noch nicht ganz sicher ob ich das so lasse denn dann kann jeder der meinen TP oder Desktop kapert sofort als root auf meine Syno. Vorher musste ich noch immer das root PWD der Syno eingeben.

 

[lugau45]

Ich habe nun extra noch ein neuen Benutzer angelegt, der auch in der Gruppe administrator ist. Dort habe ich ein verzeichnis .ssh gemacht (chmod 0700) und in .ssh eine datei (chmod 0600) authorized_keys. Beim Login kommt immer nur Passwort. Am Key in der authorized_keys kann es nicht liegen der selbe ist auch auf anderen debian Servern aktiv.
Was mich schon wundert, original stand #RSAAuthentication yes nicht in der config drin.

 

[framp]

So sieht mein Loginprotokoll aus:

xxx@obelix:~$ ssh -v root@synology
OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/xxx/.ssh/config
debug1: /home/xxx/.ssh/config line 9: Applying options for synology
debug1: /home/xxx/.ssh/config line 30: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.9 [192.168.0.9] port 22.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xxx/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.9:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:3JvRl/d6rxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
debug1: Host '192.168.0.9' is known and matches the ECDSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:77
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.0.9 ([192.168.0.9]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LC_PAPER = de_DE.UTF-8
debug1: Sending env LC_ADDRESS = de_DE.UTF-8
debug1: Sending env LC_MONETARY = de_DE.UTF-8
debug1: Sending env LC_NUMERIC = de_DE.UTF-8
debug1: Sending env LC_ALL = en_US.UTF-8
debug1: Sending env LC_TELEPHONE = de_DE.UTF-8
debug1: Sending env LC_IDENTIFICATION = de_DE.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_MEASUREMENT = de_DE.UTF-8
debug1: Sending env LC_TIME = de_DE.UTF-8
debug1: Sending env LC_NAME = de_DE.UTF-8

 

[lugau45]

Klappt nun, hat wohl was mit den Rechnten nicht richtig hingehauen, Hilfe habe ich da gefunden:
https://forum.synology.com/enu/viewtopic.php?f=90&t=116726&p=441504#p427355

How to fix for user admin (in my case it work well even with StrictModes in sshd conf):

1. Check if your pubkey is ok: it's strange but sometimes during copy/paste something happens and it's not working:

Code: Select all

ssh-keygen -l -f /var/services/homes/admin/.ssh/authorized_keys

2.

Code: Select all

chmod 755 /var/services/homes/admin

3.
a.

Code: Select all

chown admin:users /var/services/homes/admin/.ssh

b.

Code: Select all

chmod 700 /var/services/homes/admin/.ssh

4.
a.

Code: Select all

chown admin:users /var/services/homes/admin/.ssh/authorized_keys

b.

Code: Select all

chmod 644 /var/services/homes/admin/.ssh/authorized_keys