FTP/SSH-User per Public Auth

[Dawn]

Domain-FTP/SSH-User mit Public-Auth verwenden

Hi,

Ich möchte von meinem Ubuntu-Notebook auf den Webspace eines Domains per SSHFS zugreifen. Dazu möchte ich nicht irgend einen Benutzer nutzen, sondern den FTP/SSH-User des Domains welcher ja im Jail /var/www/vhosts/domainname.com/ eingesperrt ist.

Dies klappt soweit auch problemlos. Nun möchte ich mir das automatisch mounten lassen. Dazu muss ich das Public-Key Verfahren nutzen. Normalerweise ist dieser Vorgang klar:

1. Auf dem Notebook einen Public-Key generieren
2. Diesen Key aus der Datei id_dsa.pub kopieren und auf dem Server ~/.ssh/authorized_keys
einfügen.

Da der FTP/SSH-Benutzer unter /var/www/vhosts/domainname.com/ eingesperrt ist, gehe ich davon aus dass diese Datei dem entsprechend unter /var/www/vhosts/domainname.com/.ssh/ liegen müsste. Das habe ich so umgesetzt, doch leider funktioniert das nicht.

Was übersehe ich ich? Geht das überhaupt mit den Shell-Benutzern eines Domains?

Ich würde mich sehr über eine Antwort freuen

Gruss,
Dawn

 

[djrick]

Wie lautet denn der Home-Verzeichnis Pfad von dem Benutzer, den du benutzen willst?

 

[Dawn]

Laut /etc/passwd müsste das wie gesagt unter /var/www/vhosts/domainname.com liegen, dem entsprechend dachte ich dass ich den Key unter /var/www/vhosts/domainname.com/.ssh/authorized_keys einfügen müsste. Und das habe ich getan.. Nur scheint das nicht zu genügen...

 

[Roger Wilco]

dem entsprechend dachte ich dass ich den Key unter /var/www/vhosts/domainname.com/.ssh/authorized_keys einfügen müsste.

Das ist auch richtig.

Hat das Verzeichnis ~/.ssh und die Datei ~/.ssh/authorized_keys die korrekten Rechte (nur für den Benutzer lesbar)?
Wurde der Benutzer in der sshd_config gesperrt bzw. nicht freigeschaltet (je nach Policy)?
Wurde der Benutzer generell freigeschaltet?
Hat der Benutzer eine gültige Loginshell?
Was steht in den Logs des sshd?

 

[Dawn]

Hat das Verzeichnis ~/.ssh und die Datei ~/.ssh/authorized_keys die korrekten Rechte (nur für den Benutzer lesbar)?

/var/www/vhosts/domainname.com/.ssh: Rechte 600; Owner: domainuser : psacln
/var/www/vhosts/domainname.com/.ssh/authorized_keys: Rechte 600; Owner: domainuser : psacln

Wurde der Benutzer in der sshd_config gesperrt bzw. nicht freigeschaltet (je nach Policy)?

Ich sehe nicht das Nutzer hier freigeschaltet oder gesperrt werden, aber hier die Config (sorry für Fullquote, aber ich weiss einfach nicht was hier relevant ist dafür):

# Package generated configuration file
# See the sshd(8) 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
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# 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

UsePAM yes

Wurde der Benutzer generell freigeschaltet?

Wurde er, per Passwort kann ich problemlos einloggen.

Hat der Benutzer eine gültige Loginshell?

Meiner Meinung nach schon:

domainuser:x:10012:2524::/var/www/vhosts/domainname.com:/bin/sh

Was steht in den Logs des sshd?

Server refused our key

Wird beim login angezeigt (via Putty, von meinem MS Rechner aus).

reverse mapping checking getaddrinfo for work.domainname.com failed - POSSIBLE BREAK-IN ATTEMPT!

Wird im Log angezeigt (also der reverse DNS-Eintrages der IP meines Arbeitgebers). Das gleiche steht aber auch wenn ich den Public-Key unter /root/.ssh/authorized_keys eintrage, nur funktioniert das login von root dann problemlos.

Irgend etwas scheine ich zu übersehen.. Jemand eine Idee?

 

[LinuxAdmin]

Das x-Bit muss bei einem Verzeichnis schon gesetzt sein

/var/www/vhosts/domainname.com/.ssh: Rechte [COLOR="Red"]7[/COLOR]00; Owner: domainuser : psacln

 

[Dawn]

Das wars Nun klappt alles wie es sollte... Jiiiha Besten Dank!

Dumme Frage: Wieso wird das X-Bit benötigt. Meiner Meinung nach ist das doch für "eXecute"? Die eigentlich entscheidende Datei authorize_keys benötigt ja auch nur 600.

 

[wstuermer]

ohne 'x' kommst Du in das Verzeichnis nicht rein.

The  letters  rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if  the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted  deletion flag or sticky bit (t).

 

[Dawn]

Alles klar Danke für die Info.. Wieder mal etwas dazu gelernt!