ubuntuusers.de

Hallo, ist es möglich sich mittels ssh mit den piblic-key-Verfahren auch mit root ohne Passwort einzuloggen? Bisher habe ich es nur mit den user geschafft. Es betrifft nur das interne Netzwerk zu Hause.

Man kann auch für root einen Schlüssel hinterlegen und sich dann damit einloggen. Ist der root-Login erlaubt. Was ist die eventuelle Fehlermeldung?

Ahh ok. Guter Tipp, ich habe unter /root einfach das Verzeichnis .ssh angelegt und das "authorized_keys" kopiert. Jetzt funktioniert es.

Daher, das ich vorher viel getestet habe kommt nach dem einloggen auf dem client immer die Meldung

-bash: id: command not found
-bash: [: : integer expression expected

Was heißt das?

matze31 schrieb:

Daher, das ich vorher viel getestet habe kommt nach dem einloggen auf dem client immer die Meldung

-bash: id: command not found
-bash: [: : integer expression expected

Wie sind auf dem Client, die Ausgaben von:

file $(which id)
which id
echo $SHELL

?

 $ file $(which id)
/usr/bin/id: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=b2b1d382ee7f320e2277e9ab8576d2d31696df1f, stripped

which id
/usr/bin/id

 echo $SHELL
/bin/bash

matze31 schrieb:

which id
/usr/bin/id

Das passt, auf dem Client. Wird die Meldung (mit der bash) evtl. auf dem bzw. vom Server generiert?

Sorry, das war die ausgabe auf dem Server. hier auf dem Client:

$ file $(which id)
/usr/bin/id: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f8db9064d2203f35fa4c3c30f6ec4b0b7c614b5f, for GNU/Linux 3.2.0, stripped

which id
/usr/bin/id

echo $SHELL
/bin/bash

matze31 schrieb:

..., das war die ausgabe auf dem Server. hier auf dem Client:

Das passt auch.

Dann müsste/sollte man schauen/wissen, was genau mit:

-bash: id: command not found
-bash: [: : integer expression expected

gemeint ist. Geht es evtl. um ein Script (oder gleichwertig), in dem für id nicht der absolute Pfad verwendet wird und (dort wo das Script ausgeführt wird) kein Zugang zur PATH-Variable vorgesehen/möglich ist?

Mh, nicht das ich wüsste. Die Meldung kam erst, nachdem ich an der "sshd_config" geschraubt habe.

matze31 schrieb:

Die Meldung kam erst, nachdem ich an der "sshd_config" geschraubt habe.

Wie sind die Ausgaben von:

cat /etc/ssh/sshd_config | grep -i id
sudo sshd -t

?

$ cat /etc/ssh/sshd_config | grep -i id
# This is the sshd server system-wide configuration file.  See
# possible, but leave them commented.  Uncommented options override the
#PidFile /var/run/sshd.pid
# override default of no subsystems
# Example of overriding settings on a per-user basis

Auf dem Server. Und bei sudo sshd -t kam keine Ausgabe.

matze31 schrieb:

Auf dem Server. Und bei sudo sshd -t kam keine Ausgabe.

OK, d. h. die Konfiguration für den sshd ist in Ordnung und diese Ausgabe (der bash) sollte m. E., mit dem sshd-Server bzw. mit dem ssh-Zugang direkt, nichts zu tun haben.

OK. Ich habe auch zwischenzeitlich den known.hosts und die id_rsa(public) gelöscht auf Server und Client, kann es damit etwas zusammen hängen?

Hallo matze31,

da man schlecht nachvollziehen kann, was du alles gemacht hast poste ich hier mal die original ssh_config und sshd_config von einem virtuell frisch installierten Ubuntu 20.04. So kannst Du ein Backup von Deinen jetzigen Configs machen und noch mal frisch neu konfigurieren:

/etc/ssh/ssh_config:

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted 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/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

/etc/ssh/sshd_config:

#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj 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.

Include /etc/ssh/sshd_config.d/*.conf

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

#HostKey /etc/ssh/ssh_host_rsa_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

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#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 yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# 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 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 no
#PrintLastLog yes
#TCPKeepAlive yes
#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

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

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

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

Um den Passwort-losen Public-Key-Zugang zu erreichen braucht es eigentlich nichts weiter, als den Public-Key auf den Server nach /root/.ssh/authorized_keys zu kopieren (hast Du ja schon gemacht).

Der Standard-Wert für PermitRootLogin ist prohibit-password, was für Deinen Anwendungsfall genau die richtige Einstellung ist, außer Du könntest noch weiter auf forced-commands-only reduzieren, z.B. wenn Du mit root jeweils nur ein bestimmtes Skript oder Kommando ausführen willst.

LG, Newubunti

EDIT:

Ich möchte aber nich unerwähnt lassen, dass ich diese Lösung so auch nicht mal im Heimnetz anwenden würde. Denn ein Angreifer muss hier nichts weiter machen, als die Keys aus dem Ordner ~/.ssh des entsprecheden Nutzer auf dem Client zu kopieren und schon hat er Root-Zugriff auf dem Server.

Oder hat Dein Heimnetz kein Internetzugang?

Newubunti schrieb:

Ich möchte aber nich unerwähnt lassen, dass ich diese Lösung so auch nicht mal im Heimnetz anwenden würde. Denn ein Angreifer muss hier nichts weiter machen, als die Keys aus dem Ordner ~/.ssh des entsprecheden Nutzer auf dem Client zu kopieren und schon hat er Root-Zugriff auf dem Server.

Na ja, so einfach ist es für einen Angreifer auch nicht, wenn man "source address verification" auf dem Server benutzt bzw. aktiviert hat und eine whitelist für die source-IP-Adresse (des ssh-Clienten) auf dem Server benutzt.