SSH Login ohne alles

[Revolution]

Hallo zusammen,

Ich möchte einen ssh login ohne alles für den User root.

Also kein passwort kein Zertifikat nur root und dann zwei mal Enter.

PermitRootLogin habe ich auf without-Password gesetzt und das passwort auf der shadow Datei entfernt trotzdem komme ich nicht auf das System. Jemand ne Idee.

Bitte keine Diskussion ob das sicher ist

 

[RockNLol]

PermitRootLogin yes?

 

[klausk1978]

systemctl restart sshd.service

 

[kachiri]

Würde mich fast nicht einmal wundern, wenn Linux das für den root-User absolut gar nicht vorsieht...

 

[Nixdorf]

Der Wert "without-password" ist ein Alias für "prohibit-password". Damit schaltet man diese Authentifizierungsvariante ab und schränkt die Anmeldung somit auf andere Varianten wie Public-Key-Authentifizierung ein.

 

[Revolution]

Neugestart ist es natürlich

# 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 yes

# 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

# 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 no

die /etc/shadow

root::17852:0:99999:7:::

Apr  8 10:39:47 imp-db-2000293 sshd[8035]: Failed password for root from 10.x.x.x port 56378 ssh2
Apr  8 10:39:50 imp-db-2000293 sshd[8035]: Failed password for root from 10.x.x.x port 56378 ssh2
Apr  8 10:40:01 imp-db-2000293 CRON[8556]: pam_unix(cron:account): account root has password changed in future

 

[klausk1978]

@RockNLol

PermitRootLogin yes?

Das könnte man noch anführen.

Also:

in /etc/ssh/sshd_config :

PermitRootLogin without-password


dann:

sudo systemctl restart sshd.service


Hint: Schaue in der sshd_config, ob diese Optionen nicht mehrmals in diesem File definiert sind.

Und betreffend Security: Wirst schon einen Grund dafür haben, aber besser wäre einen User zur Gruppe 'wheel' (RHEL) oder 'sudo' (DEBIAN) hinzuzufügen (usermod -aG wheel/sudo $USER. Dann in der /etc/sudoers "%wheel ALL=(ALL) ALL" auf "%wheel ALL=(ALL) NOPASSWD: ALL" ändern.

Manuell die /etc/shadow zu 'bearbeiten' ist natürlich eine sehr schlechte Idee...

 

[till69]

wenn Linux das für den root-User absolut gar nicht vorsieht

Geht zumindest bei OpenWRT problemlos

 

[CoMo]

PermitRootLogin without-password sollte die Lösung sein.

 

[gaym0r]

Nein, siehe Beitrag von Nixdorf. Auch wenn KlausK1978 das auch behauptet hat.

 

[Revolution]

PermitRootLogin yes
PermitRootLogin without-password

Überschreibt sich das nicht?


Na ja es ist ein embeded System bei mir bei dem die Passwörter verloren gegangen sind. Ein Debian 8 mit ein paar sonderlocken bei Treiber... Würde gern die passwort hoheheit wieder erlangen...

Normal nehme ich ein pw von nem User aus nem anderen debian 8 in der shadow und tada... Aber hier beis ich auf granit...

Gern auch andere weg wie ich rein komme...

 

[gaym0r]

Ich versteh das nicht. Wie bearbeitest du die sshd Datei, wenn du keinen Zugang hast?

 

[CoMo]

Probier mal:

in der /etc/pam.d/sshd

Folgendes:

auth       sufficient   pam_permit.so

Siehe https://man7.org/linux/man-pages/man8/pam_permit.8.html

In der sshd_config muss dann vermutlich UsePAM yes gesetzt sein.

 

[KillerCow]

Irgendwas mit "PermitEmptyPasswords yes" oder so kommt mir dabei in den Kopf. Keine Ahnung, ob es das (noch) gibt? Kommt vielleicht auch von nem anderen Tool. Manpage dürfte helfen

 

[tollertyp]

Ich frage mich ein wenig, warum man sich mit sowas lange rumschlägt, anstatt sich kurz Zertifikate zu erzeugen.

 

[klausk1978]

via ssh-keygen und ssh-copy-id wäre die Sache ziemlich schmerzlos erledigt. Ich bin mir nämlich nicht einmal sicher, ob ssh ohne irgend einer Form von Auth funktioniert... Das wäre ja auch absolut sinnbefreit.

 

[tollertyp]

Yap. Und beim Aufruf mit übergebener Private-Key-Datei ist man auch sofort drin - da wäre sogar Boris Becker neidisch. Notfalls einen Alias schreiben dafür, ne Bash-Datei, für Windows gegebenenfalls ne cmd-Datei. Geht alles. Selbst Berechtigungen für den Private-Key bekommt man sogar unter Windows hin.

Und sich Sorgen machen, dass jemand die Private-Key-Datei erspähen könnte muss man sich mangels Sicherheitsbewusstsein ja auch nicht.

 

[CoMo]

Ich habe es hier hinbekommen.

In der /etc/pam.d/sshd:

auth       sufficient   pam_permit.so

In der /etc/ssh/sshd_config:

PermitRootLogin yes
PubkeyAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords yes
UsePAM yes

Außerdem:

systemctl stop apparmor
apt purge apparmor

Root-Login ohne Authentifizierung funktioniert:

login as: root
Welcome to Ubuntu 23.04 (GNU/Linux 6.2.16-12-pve x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
Last login: Wed Sep 27 19:32:39 2023
root@ssh-without-auth-test:~#

Sep 27 19:48:12 ssh-without-auth-test sshd[1171]: Accepted none for root from 192.168.100.65 port 59619 ssh2
Sep 27 19:48:12 ssh-without-auth-test sshd[1171]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Sep 27 19:48:12 ssh-without-auth-test systemd-logind[119]: New session 10094 of user root.
Sep 27 19:48:12 ssh-without-auth-test systemd[1]: Started session-10094.scope - Session 10094 of User root.

Falls deine Distro SELinux anstelle von AppArmor verwendet, musst du das vermutlich entsprechend deaktivieren.

 

[martinallnet]

Wenn du an die config kommst, kannst du auch einfach einen SSH-Key hinterlegen.

 

[klausk1978]

Falls deine Distro SELinux anstelle von AppArmor verwendet, musst du das vermutlich entsprechend deaktivieren.

Also wenn du so einen Workaround im professionellen Umfeld suggerierst, wirst in einem Hinterzimmer geteert und gefedert...