Brak ścieżki lub historii poleceń przez SSH po zalogowaniu się na serwerze jako ktoś inny niż root

Kiedy SSH na serwerze, jak cokolwiek innego niż root, pokazuje tylko $, a nie ścieżkę. Nie pozwoli mi także na naciśnięcie klawisza „w górę” i wyświetlenie historii poleceń, gdy nie mam SSH jako root. Jak mogę dać innym użytkownikom wymienione opcje?

Są dwa kroki, aby to osiągnąć.

Krok 1) Upewnij się, że użytkownicy używają powłoki bash. Spójrz na wpis dla każdego użytkownika w / etc / passwd i upewnij się, że kończy się w / bin / bash. Na przykład, jeśli to zobaczysz:

joeuser:x:1234:1234:Joe User:/home/joeuser:/bin/sh

następnie zmień to na:

joeuser:x:1234:1234:Joe User:/home/joeuser:/bin/bash

Użycie basha powinno rozwiązać problem ze strzałką w górę i włączyć następny krok.

Krok 2) Jeśli nadal nie widzisz monitu z bieżącym katalogiem roboczym, powiedz bash, czego chcesz. Są na to dwa sposoby. Dodaj następujący wiersz:

export PS1='\w> '

albo

1. Każdy użytkownik .bash_profile plik; LUB
2. Cały system /etc/profile plik

Ta linia przypisuje PS1 zmienna, która reprezentuje główny monit powłoki. Polecam go włożyć /etc/profile ponieważ jest to łatwiejsze i zapewnia pomocny dla wszystkich użytkowników. Jeśli użytkownik chce czegoś innego dla swojego monitu, zawsze może edytować własne .bash_profile plik.

Uwaga: jeśli twój system ma /etc/bash.bashrc następnie umieść tam linię zamiast /etc/profile.

Mój passwd(5) strona man mówi o ostatnim polu an /etc/passwd wpis, zwany „tłumaczem poleceń”:

Pole interpretera poleceń zawiera nazwę polecenia użytkownika   interpreter języka lub nazwa programu początkowego do wykonania.   Program logowania używa tych informacji do ustawienia wartości $ SHELL   zmienna środowiskowa. Jeśli to pole jest puste, domyślnie jest to   wartość / bin / sh .

Wygląda więc na to, że masz następujące opcje:

1. Umieść swoich użytkowników w /etc/passwd plik.
2. Przekazuj użytkownikom informacje dostępne przez NIS lub inne środki sieciowe.
3. Połączyć /bin/sh do jakiejś innej powłoki. Nie polecam tego, ponieważ programy najprawdopodobniej opierają się na zachowaniu istniejącego /bin/sh.

Brzmi to dość dziwnie, ponieważ - domyślnie - każdy użytkownik inny niż root powinien mieć podstawową funkcjonalność, którą opisujesz. To powiedziawszy, ten problem brzmi znajomo. Kiedykolwiek ustawię użytkownika na Ubuntu (Debian) używam adduser który działa dobrze; ale zawsze miałem problemy useradd. Jak stwierdza oficjalna strona podręcznika dla useradd:

useradd to narzędzie niskiego poziomu do dodawania użytkowników. W Debianie   administratorzy powinni zwykle używać adduser (8) zamiast tego.

Powód sprowadza się do tego, że useradd jest ostatecznie niskopoziomowym plikiem systemowym, który wymaga więcej poleceń niż tylko nazwa użytkownika, aby dodać ścieżki i informacje o powłoce dla nowego użytkownika. W przeciwieństwie, adduser to opakowanie skryptów Perla dla useradd to zapewnia ładniejszy, przyjazny dla użytkownika przepływ pracy, aby stworzyć nowego użytkownika w systemie bez większego zastanowienia. Pomyśl o tym adduser jako konfiguracja „kreatora” useradd.

Jeśli dodałeś użytkownika przez useradd są szanse, że w opcjach wiersza poleceń pominięto ustawienie konfiguracyjne. Więc technicznie, dodałeś użytkownika do systemu, ale niewiele więcej w sposobie konfiguracji systemu. W przeciwieństwie, adduser jest zaprojektowany do obsługi wszystkich różnych podstaw.

Wiedząc o tym, zalecałbym usunięcie każdego użytkownika, który już utworzyłeś w ten sposób; oczywiście zmiana [username] do rzeczywistej nazwy użytkownika:

sudo deluser --remove-home [username]

A następnie ponownie utwórz tego użytkownika za pomocą adduser lubię to:

sudo adduser [username]