SSH Zugriff

tigertim08

Member
Jun 16, 2019
7
0
6
35
Hallo zusammen,

ich bin relativ neu in der Proxmox Thematik und habe die ersten VMs am laufen. Jetzt wollte ich mich über das Terminal per ssh mit einer VM verbinden komme aber nicht rein. Gehe ich über die Weboberfläche und dort über die Konsole klappt alles wunderbar. Scheint als wäre irgendwo eine firewall aktiv die SSH Verbindungen blockt...

2019-08-29_07-47-56.png

Kann hier jemand helfen?
Danke
 
Hallo Tim,

wenn SSH Verbindungen geblockt würden, solltest du gar nicht bis zum Password-Prompt kommen. Ist das Tastatur-Layout im Terminal korrekt? Ansonsten weiß ich auch nicht, woran das liegen könnte.

Beste Grüße,
Fabi
 
Könntest du /etc/ssh/sshd_config von deiner VM posten?
Wenn du über die Weboberfläche reingehst und
Code:
ssh tim@localhost
machst, funktioniert das?

Beste Grüße,
Fabi
 
Ja, über die Oberfläche komme ich rein. Inhalt ist:

Code:
#    $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_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
#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

# 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
 
Ich muss mich dabei Anschließen und bei mir klappt es auch nach 48 Stunden nicht...
Traceroute und Pinganfragen sind Zielführend erfolgreich.

Tastaturlayout auch schon ausgeschlossen.

sshd_config ist wie hier zu sehen.
Ja, über die Oberfläche komme ich rein. Inhalt ist:

Code:
#    $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_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
#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

# 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
 
Last edited:
Könntest du /etc/ssh/sshd_config von deiner VM posten?
Wenn du über die Weboberfläche reingehst und
Code:
ssh tim@localhost
machst, funktioniert das?

Beste Grüße,
Fabi
Code:
root@debian-test:~#
root@debian-test:~# passwd
New password:
Retype new password:
passwd: password updated successfully
root@debian-test:~# ssh root@localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:nqsQdD4qKs+Qcw***********Bgl4DBfGW2c.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
 
Code:
root@debian-test:~#
root@debian-test:~# passwd
New password:
Retype new password:
passwd: password updated successfully
root@debian-test:~# ssh root@localhost
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:nqsQdD4qKs+Qcw***********Bgl4DBfGW2c.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:

Ist der Parameter PermitRootLogin yes gesetzt in deiner /etc/ssh/sshd_config? Sollte eigentlich bei PVE per default so gesetzt sein, aber ich frage sicherheitshalber mal.

EDIT: Falls er nicht gesetzt ist: Hast du vielleicht PVE nachträglich auf einem Debian installiert? Ich glaube bei Debian ist der per default nicht gesetzt und hat dann den Default-Wert prohibit-password
 
Last edited:
Ist der Parameter PermitRootLogin yes gesetzt in deiner /etc/ssh/sshd_config? Sollte eigentlich bei PVE per default so gesetzt sein, aber ich frage sicherheitshalber mal.

EDIT: Falls er nicht gesetzt ist: Hast du vielleicht PVE nachträglich auf einem Debian installiert? Ich glaube bei Debian ist der per default nicht gesetzt und hat dann den Default-Wert prohibit-password
Auf dem Hostsystem oder Gastsystem?

Das Hostsystem ist via. sshkeys ohne login abgesichert
Gastsystem ist yes
 
Ah okay, das Problem besteht also beim Verbinden mit dem Gast? bzw. auch vom Gast selbst über localhost mit sich selbst? Mein Fehler, ich hatte den Text des ursprünglichen Beitrags nur überflogen und dachte es geht um SSH-Login auf dem PVE-Host ;)

Was sagt denn /var/log/auth.log ? Eventuell loggt SSH hier ja die Ursache für dein Problem.
 
Ah okay, das Problem besteht also beim Verbinden mit dem Gast? bzw. auch vom Gast selbst über localhost mit sich selbst? Mein Fehler, ich hatte den Text des ursprünglichen Beitrags nur überflogen und dachte es geht um SSH-Login auf dem PVE-Host ;)

Was sagt denn /var/log/auth.log ? Eventuell loggt SSH hier ja die Ursache für dein Problem.
Tatsächlich! Das Gastsystem benötigt hier im Standart Container Template die explizite Anweisung, trotz auskommentierung von "Werk"... Was natürlich etwas misslich ist wenn man Prozesse automatisieren möchte. Gibt es hierfür schon Lösungsansätze?

# Authentication:

Code:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

Zu

Code:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
 
Tatsächlich! Das Gastsystem benötigt hier im Standart Container Template die explizite Anweisung, trotz auskommentierung von "Werk"... Was natürlich etwas misslich ist wenn man Prozesse automatisieren möchte. Gibt es hierfür schon Lösungsansätze?
Ja, unsere CT-Templates übernehmen hier die Standardeinstellung von Debian (probit-password ist der Standard, wenn die Option auskommentiert ist). Wenn du das ganze automatisieren willst, würde ich das ganze einfach einmal einstellen und dann ein Template aus dem Container generieren.
 
  • Like
Reactions: equestrian
Ja, unsere CT-Templates übernehmen hier die Standardeinstellung von Debian (probit-password ist der Standard, wenn die Option auskommentiert ist). Wenn du das ganze automatisieren willst, würde ich das ganze einfach einmal einstellen und dann ein Template aus dem Container generieren.
Ok! Die Netzwerkkonfiguration wird dementsprechend dann Überschrieben?
 
Wenn du einen neuen Container aus einem Template klonst, wird er zunächst die Netzwerkkonfiguration behalten. Du kannst sie allerdings dann über die Container-Einstellungen bearbeiten, so wie bei jedem anderen Container auch.

Es gibt allerdings noch einen zweiten Weg, Templates zu erstellen, und zwar in dem du ein Backup des containers machst, und dieses dann in das template-verzeichnis kopierst [1]. Somit verhält sich der Container dann so wie eins der von uns erstellten Templates, wo du beim erstellen des Containers Password/SSH-Key/Netzwerkkonfiguration erstellen kannst. Habe ich aber persönlich noch noch nicht selbst gemacht, kann dir also nicht garantieren, dass die Anleitung hier auch 100% stimmt ;)

[1] https://www.geekbundle.org/proxmox-container-template-erstellen/
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!