Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 28
  1. #1

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

    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:
    Code:
    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...
    Code:
    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:
    Code:
    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?
    DS410 (DSM 4.3-3827-u7) / 4x WD40EFRX 4TB / Synology Hybrid RAID
    DS411 (DSM 6.1.1-15101-u4) / 4x WD60EFRX 6TB / Synology Hybrid RAID

  2. #2
    Anwender Avatar von itari
    Registriert seit
    15.05.2008
    Beiträge
    21.945
    Blog-Einträge
    25

    Standard

    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
    207+ Basic(2x500) [1618] | 509+ Basic(1x500,4x2000) [2166] | 2411+ Basic-SSD(50), Raid-5(4x2000), SHR(3x750+1x1000+2x1500) [2166]

    Synology-Kontakt-Formular
    Come to the dark side, we have cookies!

  3. #3

    Standard

    Zitat Zitat von itari Beitrag anzeigen
    Kannst denn als User 'annika' mit der /bin/ash anmelden und dann die /opt/bin/bash aufrufen?
    Ja, das klappt.


    Zitat Zitat von itari Beitrag anzeigen
    Vielleicht sind ja einige Pfade nicht freigegeben?
    Tja, das mag sein ... aber welche?! *grübel*


    Zitat Zitat von itari Beitrag anzeigen
    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...
    DS410 (DSM 4.3-3827-u7) / 4x WD40EFRX 4TB / Synology Hybrid RAID
    DS411 (DSM 6.1.1-15101-u4) / 4x WD60EFRX 6TB / Synology Hybrid RAID

  4. #4
    Moderator Avatar von jahlives
    Registriert seit
    19.08.2008
    Beiträge
    18.259
    Blog-Einträge
    20

    Standard

    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
    Was im Leben zählt, ist nicht, dass wir gelebt haben. Sondern, wie wir das Leben von anderen verändert haben (Rolihlahla "Nelson" Mandela 1918-2013)

  5. #5
    Anwender Avatar von itari
    Registriert seit
    15.05.2008
    Beiträge
    21.945
    Blog-Einträge
    25

    Standard

    Zitat Zitat von Annika Hansen Beitrag anzeigen
    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
    207+ Basic(2x500) [1618] | 509+ Basic(1x500,4x2000) [2166] | 2411+ Basic-SSD(50), Raid-5(4x2000), SHR(3x750+1x1000+2x1500) [2166]

    Synology-Kontakt-Formular
    Come to the dark side, we have cookies!

  6. #6

    Standard

    Zitat Zitat von jahlives Beitrag anzeigen
    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...


    Zitat Zitat von jahlives Beitrag anzeigen
    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.


    Zitat Zitat von itari Beitrag anzeigen
    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".
    DS410 (DSM 4.3-3827-u7) / 4x WD40EFRX 4TB / Synology Hybrid RAID
    DS411 (DSM 6.1.1-15101-u4) / 4x WD60EFRX 6TB / Synology Hybrid RAID

  7. #7
    Anwender Avatar von itari
    Registriert seit
    15.05.2008
    Beiträge
    21.945
    Blog-Einträge
    25

    Standard

    Zitat Zitat von Annika Hansen Beitrag anzeigen
    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
    207+ Basic(2x500) [1618] | 509+ Basic(1x500,4x2000) [2166] | 2411+ Basic-SSD(50), Raid-5(4x2000), SHR(3x750+1x1000+2x1500) [2166]

    Synology-Kontakt-Formular
    Come to the dark side, we have cookies!

  8. #8
    Anwender
    Registriert seit
    16.09.2011
    Beiträge
    90

    Standard

    Zitat Zitat von jahlives Beitrag anzeigen
    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:
    Code:
    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.
    Zitat Zitat von Annika Hansen Beitrag anzeigen
    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.

    NAS: DS 211+ [1944], 2 x WD20EARS [2TB] RAID-1, 4 x WD30EZRX [3TB] via USB
    Workstation: 27" iMac Core i7 @3,4GHz, 16GB RAM, 256GB SSD, 2TB SATA, 2GB HD6970M, Lion
    HTPC: Zotac 9300 ITX WiFi, C2D E8400 @3GHz, 4GB RAM, 160GB SDD, MediaPortal 1.2.0 SVN, Win 7
    Storage Array: Adaptec 3085, 22 x WD2002FYPS [2TB] RAID 6 mit Hotspare
    Router: Netgear WNDR3700 [DD-WRT], Linksys E4200 [DD-WRT], AVM FRITZ!Box 7390 [Stock Firmware]
    Displays: Samsung 24" 244T, Asus 27" VE278Q, Samsung 55" LE-55A956

  9. #9
    Moderator Avatar von jahlives
    Registriert seit
    19.08.2008
    Beiträge
    18.259
    Blog-Einträge
    20

    Standard

    Zitat Zitat von scythe42 Beitrag anzeigen
    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
    Was im Leben zählt, ist nicht, dass wir gelebt haben. Sondern, wie wir das Leben von anderen verändert haben (Rolihlahla "Nelson" Mandela 1918-2013)

  10. #10
    Anwender
    Registriert seit
    16.09.2011
    Beiträge
    90

    Standard

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

    NAS: DS 211+ [1944], 2 x WD20EARS [2TB] RAID-1, 4 x WD30EZRX [3TB] via USB
    Workstation: 27" iMac Core i7 @3,4GHz, 16GB RAM, 256GB SSD, 2TB SATA, 2GB HD6970M, Lion
    HTPC: Zotac 9300 ITX WiFi, C2D E8400 @3GHz, 4GB RAM, 160GB SDD, MediaPortal 1.2.0 SVN, Win 7
    Storage Array: Adaptec 3085, 22 x WD2002FYPS [2TB] RAID 6 mit Hotspare
    Router: Netgear WNDR3700 [DD-WRT], Linksys E4200 [DD-WRT], AVM FRITZ!Box 7390 [Stock Firmware]
    Displays: Samsung 24" 244T, Asus 27" VE278Q, Samsung 55" LE-55A956

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. ssh für root funktioniert für user nicht
    Von wired2051 im Forum Terminal-Dienste (Telnet, SSH) - Linux-Konsole
    Antworten: 11
    Letzter Beitrag: 06.01.2015, 20:19
  2. Antworten: 4
    Letzter Beitrag: 01.11.2010, 15:43
  3. ssh für root funktioniert für user nicht
    Von wired2051 im Forum Netzwerkkonfiguration
    Antworten: 6
    Letzter Beitrag: 12.05.2010, 10:38
  4. Zugriff via SSH oder Telnet mit non-root user
    Von cccc im Forum Terminal-Dienste (Telnet, SSH) - Linux-Konsole
    Antworten: 34
    Letzter Beitrag: 08.01.2010, 16:50
  5. Zugriff via SSH oder Telnet mit non-root user
    Von cccc im Forum Netzwerkkonfiguration
    Antworten: 34
    Letzter Beitrag: 08.01.2010, 16:50

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •