SSH-Zugriff für non-root User funkioniert nicht mit bash als Shell

[Annika Hansen]

Hallo zusammen,

ich bin beim Aufsetzen meiner Umgebung auf ein Problem/Phänomen gestoßen, das ich nicht so recht verstehe. Und zwar geht es um den Zugriff vom meinem PC (Windows7 64-Bit Pro) über SSH auf meine DS410 (DSM 3.1-1748) als non-root-User:

Fall 1:
In der "/etc/passwd" habe ich als Standard-Shell gesetzt:

annika:x:1026:100:Ich:/volume1/homes/annika:/bin/ash

Der Zugriff funktioniert wie erwartet einwandfrei. Ich bin als User annika eingeloggt und lande wie gewünscht in "/volume1/homes/annika".


Fall 2:
Jetzt habe ich in der "/etc/passwd" die bash als Shell gesetzt...

annika:x:1026:100:Ich:/volume1/homes/annika:/opt/bin/bash

... und dieser Zugriff schlägt fehl.

Hier der Auszug wenn ich ssh mit der Option -v starte:

C:\Program Files (x86)\DeltaCopy>ssh -v annika@ds410 -i /cygdrive/d/bin/putty-0.6/.ssh/annika.key -o UserKnownHostsFile=/cygdrive/d/bin/putty-0.6/.ssh/known_hosts
"
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Connecting to ds410 [192.168.1.210] port 22.
debug1: Connection established.
debug1: identity file /cygdrive/d/bin/putty-0.6/.ssh/annika.key type -1
debug1: identity file /cygdrive/d/bin/putty-0.6/.ssh/annika.key-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: Host 'ds410' is known and matches the RSA host key.
debug1: Found key in /cygdrive/d/bin/putty-0.6/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /cygdrive/d/bin/putty-0.6/.ssh/annika.key
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to ds410 ([192.168.1.210]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Permission denied, please try again.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to ds410 closed.
Transferred: sent 2528, received 2280 bytes, in 0.1 seconds
Bytes per second: sent 48615.4, received 43846.2
debug1: Exit status 1

Wenn ich das ganze als User root probiere, dann klappt der SSH-Zugriff egal ob ich /bin/ash oder /opt/bin/bash als Shell beim User root eingetragen habe.

Habt Ihr eine Idee, was da falsch läuft bzw. ich vergessen oder falsch konfiguriert habe habe?

 

[itari]

Kannst denn als User 'annika' mit der /bin/ash anmelden und dann die /opt/bin/bash aufrufen? Vielleicht sind ja einige Pfade nicht freigegeben? Wenn das mit dem /opt/bin/bash auf der Kommandozeilte geht, dann setz den Aufruf doch in die .profile ... dann hast doch auch alles.

Itari

 

[Annika Hansen]

Kannst denn als User 'annika' mit der /bin/ash anmelden und dann die /opt/bin/bash aufrufen?

Ja, das klappt.

Vielleicht sind ja einige Pfade nicht freigegeben?

Tja, das mag sein ... aber welche?! *grübel*

Wenn das mit dem /opt/bin/bash auf der Kommandozeilte geht, dann setz den Aufruf doch in die .profile ... dann hast doch auch alles.

Das ist aber nicht so ganz "im Sinne des Erfinders". Es ist etwas anderes, wenn ich die bash als Login-Shell setze, als mich über die ash einzuloggen und dann im .profile die nächste Shell aufzurufen.


Irgendwie ist das merkwürdig...

 

[jahlives]

Ist denn die bash in shells eingetragen (/etc/shells)?
Als Tipp noch: es kann ganz lustige Effekte geben wenn du z.B. dem root die Bash verpasst und dann die Firmware neuinstallierst. sobald /opt nicht mehr vorhanden ist, scheitert dann der Login. Wenn schon würde ich als shell eher /volume1/@optware/bin/bash eintragen, da dieser Pfad auch nach einer FW-Installation (oder Reset) noch vorhanden sein sollte

 

[itari]

Es ist etwas anderes, wenn ich die bash als Login-Shell setze, als mich über die ash einzuloggen und dann im .profile die nächste Shell aufzurufen.

Du machst mir ganz neugierig. Was ist denn dann ganz anders???

Itari

 

[Annika Hansen]

Ist denn die bash in shells eingetragen (/etc/shells)?

Yepp, das ist sie. Allerdings habe ich das Gefühl, dass das "syno"-Linux sich nicht groß um die Auswertung der "/etc/shells" kümmert...

Als Tipp noch: es kann ganz lustige Effekte geben wenn du z.B. dem root die Bash verpasst und dann die Firmware neuinstallierst. sobald /opt nicht mehr vorhanden ist, scheitert dann der Login. Wenn schon würde ich als shell eher /volume1/@optware/bin/bash eintragen, da dieser Pfad auch nach einer FW-Installation (oder Reset) noch vorhanden sein sollte

Danke für den Hinweis ... da hatte ich noch nicht dran gedacht. Das werde ich gleich ändern.

Du machst mir ganz neugierig. Was ist denn dann ganz anders???

Nun, die Login-Shell ist diejenige, die beim Anmelden durchlaufen wird, und da greifen gerade bei der bash unterschiedliche Mechanismen.

Sofern die bash als Login-Shell ausgeführt wird, werden die nachfolgenden aufgeführten Dateien gelesen und in dieser Reihenfolge ausgeführt (sofern sie vorhanden sind):
/etc/profile
~/.bash_profile
~/.bash_login
~/.profile

Wird die bash nicht als Login-Shell ausgeführt, dann werden folgende Dateien gelesen und in dieser Reihenfolge ausgeführt (sofern sie vorhanden sind):
/etc/bash.bashrc
~/.bashrc

Das Ergebnis der beiden "Varianten" sind unterschiedlich gesetzte Environments.


Und, ich möchte verstehen, warum die bash beim User "root" als Login-Shell akzeptiert wird, jedoch nicht für den User "annika".

 

[itari]

Nun, die Login-Shell ist diejenige, die beim Anmelden durchlaufen wird, und da greifen gerade bei der bash unterschiedliche Mechanismen.

Sofern die bash als Login-Shell ausgeführt wird, werden die nachfolgenden aufgeführten Dateien gelesen und in dieser Reihenfolge ausgeführt (sofern sie vorhanden sind):
/etc/profile
~/.bash_profile
~/.bash_login
~/.profile

Wird die bash nicht als Login-Shell ausgeführt, dann werden folgende Dateien gelesen und in dieser Reihenfolge ausgeführt (sofern sie vorhanden sind):
/etc/bash.bashrc
~/.bashrc

Das Ergebnis der beiden "Varianten" sind unterschiedlich gesetzte Environments.


Und, ich möchte verstehen, warum die bash beim User "root" als Login-Shell akzeptiert wird, jedoch nicht für den User "annika".

Also, in meinen Augen mögen da total unterschiedliche Start-Dateien durchlaufen werden, aber die Mechanik ist die gleiche - bei allen Shells - egal nun, ob die eine Datei so oder so heisst. Denn du kannst dir immer ein Environment zusammenstellen, wie du magst ... und wenn du willst, kannst dir auch Shell-Weichen schreiben ... ist also kein wirkliches Argument für unterschiedliche Mechanismen, eher für unterschiedliche Dateinamen *gg*

Zu deiner Forschungstätigkeit ein Tipp, schalte dir einen Trace- oder Debug-Mode im Shell-Aufruf ein und protokollieren in eine Datei ... dann siehst, ob Rechte irgendwo fehlen ...

Itari

 

[scythe42]

Wenn schon würde ich als shell eher /volume1/@optware/bin/bash eintragen, da dieser Pfad auch nach einer FW-Installation (oder Reset) noch vorhanden sein sollte

Sollte dir @optware abhanden kommen hilft das auch nicht. Die shell von root in der /etc/passwd gegen etwas auszutaushen, was nicht zum Basis-System von der DS gehört ist eine wahnsinnig schlechte Idee.

So wird's richtig gemacht (Beispiel Bash) für root:

mv /root/.profile /root/.bash_profile
cat > /root/.profile << "EOF"
# Login shell auf /opt/bin/bash ändern, wenn diese existiert
[ -f /opt/bin/bash ] && exec /opt/bin/bash --login
EOF

Hinweise

• .profile wird immer beim initiellen login angezogen, deswegen kommt da nur die Aenderung der login shell rein, bash selbst zieht diese Datei später nicht an.
• bash --login ersetzt die aktuelle Shell, d.h. die Alte wird wirklich ersetzt (es läuft kein /bin/ash Prozess mehr!)
• Nach einem Reset oder einem Upgrade wird auch /root auf den Auslieferungsstandard gesetzt. Backup also nicht vergessen, wenn man seine ganzen Einstellungen und Configs nicht verlieren will.

YAllerdings habe ich das Gefühl, dass das "syno"-Linux sich nicht groß um die Auswertung der "/etc/shells" kümmert...

/etc/shells wird im Bezug auf Logins von chsh verwendet, womit man auch als normaler User seine Shell ändern kann. Die /etc/passwd editiert man eigentlich schon lange nicht mehr. Mit chsh und anderen Tools vermeidet man halt dumme Tippfehler. Standardmässig ist bei der Syno aber kein chsh dabei. *sigh*

Auf der DS nutzen busybox (für su), netatalk, PAM, procmail und uclibc die /etc/shells.

 

[jahlives]

Sollte dir @optware abhanden kommen hilft das auch nicht.

das musst du mir aber erklären Wie kann dir denn @optware abhanden kommen? So ganz von alleine sicher nicht. Da muss der admin manuell kräftig nachhelfen

 

[scythe42]

Probleme mit volume1. Ein RAID schützt nicht vom Filesystem Issues...

 

[momoleta]

Problem mit non-root SSH zugriff

Ich habe warscheindliche ein einfaches (ähnliches) Problem für Linux Pro`s:

Ich versuche mich als normaler User via SSH auf mein NAS einzuloggen. Beim Root funktioniert es, aber bei allen anderen Usern versagt Putty den Dienst und stürzt ohne Meldung ab. Hab mal die Session gellogt und angeschaut: Steht nur Permission denied drin. Hat da jemand eine Idee???
Warscheindlich fehlt mir ein Start-Script.

PS. Eintrag /var/services/homes/User:/bin/ash ist /etc/passwd beim User umden es geht gemacht.

 

[scythe42]

Mit Key oder mit Passwort? Wie sieht deine shd_config aus?

 

[itari]

Ich versuche mich als normaler User via SSH auf mein NAS einzuloggen.

Wenn du dich per telnet anmeldest, geht es ???

Itari

 

[jahlives]

Oder mittels su User kann man es auch kurz testen

 

[momoleta]

Danke für die Antworten und Ideen.

@scythe42
Das wäre mit Passwort. Die Sache mit Key wäre dann einmal (in ferner Zukunft) mein Endziel. Anbei noch die sshd_conf Datei.

#OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 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 change a
# default value.

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

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# 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

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile    .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and 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 yes
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
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
ChrootDirectory none
#ChrootDirectory /var/services/homes/%u
#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem    sftp    /usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp -f DAEMON -l VERBOSE
#Subsystem       sftp    /usr/syno/sbin/sftp-server -l DEBUG3
Subsystem    sftp    internal-sftp

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

@Itari
Nein dass habe ich noch nicht Probiert, aber das wäre auch gar nicht das Ziel. Die gesamte Übung ist dafür da, dass ich eine SSH-Tunnel zu meinem NAS habe, durch welchen ich dann Verschlüssel drauf zugreifen kann (Siehe: http://pcloadletter.co.uk/2011/02/06/synology-ssh-tunnelling/ nur noch mit Dyndns anstelle von Lokal wie in der Anleitung).

@jahlives
root anmelden su Benutzer geht.
SSH direkt Benutzer anmelden geht nicht.

Danke für euere Mühe.

 

[jahlives]

Okay wenn su geht dann su DEIN_BENUTZER und ls -al ~/ machen. Kommt dann der Inhalt des Homeverzeichnisses deines Users?

 

[momoleta]

Jo der Inhalt meines Homeverzeichnisses wird angezeigt.

 

[jahlives]

hat dein User eine .profile Datei in seinem Home?

 

[momoleta]

@jahlives


Nein das hat er nicht. Hast du eine Vorlage für diese Datei??? Ich kann ja nicht einfach die .profile vom root nehmen???

Danke für deine Hilfe.

 

[jahlives]

wenn du die von root nimmst wirst du sie aber anpassen müssen