Zamierzam uruchomić drugą sshdinstancję na nieuprzywilejowanym porcie (np. 2222) z własnym plikiem konfiguracyjnym.

Oczywiście sshdproces nie może się setuidzalogować, ponieważ użytkownicy inni niż ten, który uruchamia sshddemona, jest oczywiście niemożliwy.

Czy można jednak mieć działającego sshddemona, który będzie działał dla aktualnie działającego użytkownika? W moim przypadku byłoby dobrze.

Próbowałem uruchomić sshdinstancję z własnym plikiem konfiguracyjnym i kluczem hosta, a sshdproces się uruchamia (brak skarg na brak uprawnień użytkownika root, jak niektóre polecenia), jednak kiedy próbuję połączyć się z tym portem, sshdproces umiera.

$ /usr/sbin/sshd -dD -h .ssh/id_rsa -p 2222 
debug1: sshd version OpenSSH_5.6p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-dD'
debug1: rexec_argv[2]='-h'
debug1: rexec_argv[3]='.ssh/id_rsa'
debug1: rexec_argv[4]='-p'
debug1: rexec_argv[5]='2222'
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug1: fd 6 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 5, 5
Connection from ::1 port 57670
debug1: Client protocol version 2.0; client software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: list_hostkey_types: 
No supported key exchange algorithms
debug1: do_cleanup
debug1: do_cleanup
debug1: audit_event: unhandled event 12

debug1: setgroups() failed: Operation not permittedLinia oczywiście odstaje, ale nie umrze, dopóki nie próbuje akceptować połączenia.

Po odrobinie przekopania się zrozumiałem.

Rozpocznij proces od sshd -f ~/.ssh/sshd_configmiejsca, /.ssh/sshd_configw którym utworzyłeś nowy plik. Wśród innych opcji (takich jak inny klucz hosta, inny port itp.) Musisz dodać linię UsePrivilegeSeparation no. Zapobiegnie to sshdpróbie wykonania jakichkolwiek połączeń setuidlub setgidpołączeń i pozwoli na kontynuowanie działania jako użytkownik i akceptowanie połączeń jako użytkownika.

EDYCJA: Kilka chwil po tym, jak to rozgryzłem, ktoś tweetował ten link do mnie, co potwierdza, że ​​jest to właściwy sposób: http://cygwin.com/ml/cygwin/2008-04/msg00363.html

W ramach aktualizacji tego wątku OpenSSH w wersji 7.5 wycofał opcję UsePrivilegeSeparation, uniemożliwiając wyłączenie separacji uprawnień. Wygląda na to, że uruchomienie SSHD jako użytkownik jest teraz niemożliwe.

Zobacz https://www.openssh.com/releasenotes.html

Sprawdziłem szczegółowo możliwość uruchomienia usługi sshd jako zwykły użytkownik. Szczegół wersji programu:

wersja sshd OpenSSH_7.4, OpenSSL 1.0.2k

W końcu po rozwiązaniu wielu błędów doszedłem do punktu, w którym SSHD przerwał działanie z następującym błędem:

Próba zapisania danych logowania przez użytkownika innego niż root (przerywanie)

Sprawdziłem kod źródłowy, aby zobaczyć, czy można rozwiązać problem bez zmiany kodu źródłowego. Zobacz kod tutaj . Część kodu powodująca przerwanie programu:

#ifndef HAVE_CYGWIN
    if (geteuid() != 0) {
        logit("Attempt to write login records by non-root user (aborting)");
        return (1);
    }
#endif

Sprawdza uprawnienia użytkownika (geteuid() != 0)i powoduje problem.

Zakładając, co @magiclantern zauważyło powyżej i zakładając, że nie chcesz łatać,sshd czy coś takiego jak Dropbear będzie dla ciebie działać? Jest używany w wielu urządzeniach wbudowanych, które potrzebują serwera ssh o mniejszej powierzchni (i mniejszej liczbie funkcji / konfiguracji).

Oto srib bash użytkownika w oparciu o odpowiedź Bo Jeanesa, że:

• Utwórz działający katalog w domu
• generuj klucze serwera w działającym katalogu
• wygeneruj podstawowy plik konfiguracyjny z plikiem pid zlokalizowanym w działającym katalogu
• uruchom demona SSH

mkdir ${HOME}/custom_ssh
ssh-keygen -f ${HOME}/custom_ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f ${HOME}/custom_ssh/ssh_host_dsa_key -N '' -t dsa
echo "Port 2222
HostKey ${HOME}/custom_ssh/ssh_host_rsa_key
HostKey ${HOME}/custom_ssh/ssh_host_dsa_key
AuthorizedKeysFile  .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes
Subsystem   sftp    /usr/lib/ssh/sftp-server
PidFile ${HOME}/custom_ssh/sshd.pid" > ${HOME}/custom_ssh/sshd_config
/usr/bin/sshd -f ${HOME}/custom_ssh/sshd_config
echo "
--------
Process ID : ${HOME}/custom_ssh/sshd.pid
-------"

• OpenSSH_7.9p1, OpenSSL 1.1.1a 20 listopada 2018
• pam auth (testowane z tym samym lokalnym i zdalnym użytkownikiem)