Настоятельно просим вас при общении соблюдать Правила форума и законы РФ. Наша тематика вне политики, поэтому воздержитесь от обсуждения ситуации на Украине и связанных с ней событий, независимо от того, какую сторону вы поддерживаете.
Также напоминаем, что наш форум находится в доменной зоне .ru, физически расположен на российских серверах и мы соблюдаем действующее законодательство России. Любые сообщения о политике будут удаляться.
Linux Forum → Ubuntu, Linux Mint → Добавить пользователя в группу SSH
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Здравствуйте, банальный вопрос, но, как добавить пользователя в группу, что бы через этого пользователя можно было удаленно заходить по протоколу ssh?
P.S.
Я на компьютер 1 поставил shh сервер, здесь у меня пользователь ozone
На компьютере 2 задаю команду ozone@23.434.11.91
ozone - единственная учетная запись компьютера 1
23.434.11.91 - это IP адрес компьютера 1
Появляется запрос на введения пароля но после ввода пароля, пользователя ozone компьютера 1 ничего не происходит.
myr4ik07, нужно смотреть настройки ssh-сервера, откуда и что разрешено.
На компьютере 2 задаю команду ozone@23.434.11.91
Нужно так:
ssh ozone@23.434.11.91...хотя если вы имеете одинаковые учётные записи на обоих компьютерах, имя можно не указывать. Есть ли пользователь ozone на втором компьютере?
Добавьте в команду опцию -v, чтобы вывод в консоль стал подробнее и покажите его.
myr4ik07, нужно смотреть настройки ssh-сервера, откуда и что разрешено.
myr4ik07 пишет:На компьютере 2 задаю команду ozone@23.434.11.91
Нужно так:
ssh ozone@23.434.11.91...хотя если вы имеете одинаковые учётные записи на обоих компьютерах, имя можно не указывать. Есть ли пользователь ozone на втором компьютере?
Добавьте в команду опцию -v, чтобы вывод в консоль стал подробнее и покажите его.
Подскажите, в какой строке конфигурационного файла искать разрешенные данные?
Я забыл просто дописать ssh, я ввожу правильно команду.
ssh ozone@23.434.11.91P.S. У меня выходит так, на компьютере 1 есть учетная запись ozone
и на компьютере 2 есть учетная запись ozone
на обоих компьютерах учетная запись ozone с одинаковыми паролями
Не знаю, правильно ли "присобачил" параметр, но вывод вышел таков
ozone@dekstop:~$ ssh -v ozone@91.124.78.46
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 91.124.78.46 [91.124.78.46] port 22.
debug1: Connection established.
debug1: identity file /home/ozone/.ssh/id_rsa type -1
debug1: identity file /home/ozone/.ssh/id_rsa-cert type -1
debug1: identity file /home/ozone/.ssh/id_dsa type -1
debug1: identity file /home/ozone/.ssh/id_dsa-cert type -1
debug1: identity file /home/ozone/.ssh/id_ecdsa type -1
debug1: identity file /home/ozone/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.46
debug1: no match: dropbear_0.46
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 09:53:5a:be:05:11:23:a1:4c:a8:52:f3:55:83:df:c9
debug1: Host '91.124.78.46' is known and matches the RSA host key.
debug1: Found key in /home/ozone/.ssh/known_hosts:2
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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ozone/.ssh/id_rsa
debug1: Trying private key: /home/ozone/.ssh/id_dsa
debug1: Trying private key: /home/ozone/.ssh/id_ecdsa
debug1: Next authentication method: password
ozone@91.124.78.46's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
ozone@91.124.78.46's password: Добавлю еще вот это
ozone@dekstop:~$ ssh ozone@91.124.78.46
ozone@91.124.78.46's password:
Permission denied, please try again.то есть введя пароль требует его ввести снова
Покажите файл /etc/ssh/ssh_config.
Как мне кажется, меня не авторизует по паролю, потому что авторизация стоит по ключу, правильно?
Как мне кажется, меня не авторизует по паролю, потому что авторизация стоит по ключу, правильно?
Покажите файл /etc/ssh/ssh_config.
Покажите файл /etc/ssh/ssh_config.
Вот содержимое файлика
# Package generated configuration file
# See the sshd_config(5) 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
HostKey /etc/ssh/ssh_host_ecdsa_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
# 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
myr4ik07, правило №1
никаких ключей в каталогах в /etc/ прописано быть НЕ должно. Все ключи пишутся у юзеров
Правило №2
Пара публичный/секретный ключ создаётся НА клиенте (там, ОТКУДА входите).
Правило №3
Секретный ключ НИКОГДА не покидает своего места. Обычно он лежит в $HOME/.ssh/
(публичный имеет то же самое имя, но расширение .pub)
Правило №4
Надо переносить ключ от клиента, к серверу. В домашний каталог КУДА вы входите, в конец файла $HOME/.ssh/authorized_keys
Вы что-то (если не всё) делаете не так.
Lupo Alberto пишет:Покажите файл /etc/ssh/ssh_config.
Вот содержимое файлика
# Package generated configuration file # See the sshd_config(5) 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 HostKey /etc/ssh/ssh_host_ecdsa_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 # 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
По инструкции, которых много, пишется:
1)Установи ssh сервер на систему которой будет управлятся
2)На другой системе запусти команду для соединения
Все, вот и вся инструкция.
Буду признателен привести вашу инструкцию или помогите найти ошибку, с того, что вы написали я не нашел ответа на вопрос.
myr4ik07, меньше читайте бреда.
вам не нагуглить нормальную инструкцию?
на самом деле, в каждом случае всегда по разному, потому я просто устану писать для вас инструкции, а вы их выбирать. Лучше расскажите, что вы хотите сделать. А я(если такое делал), расскажу как. Или кто другой расскажет.
Общие правила я вам уже дал. Что не понятно - пишите. (откуда мне знать, что вам непонятно?)
myr4ik07, меньше читайте бреда.
вам не нагуглить нормальную инструкцию?
на самом деле, в каждом случае всегда по разному, потому я просто устану писать для вас инструкции, а вы их выбирать. Лучше расскажите, что вы хотите сделать. А я(если такое делал), расскажу как. Или кто другой расскажет.Общие правила я вам уже дал. Что не понятно - пишите. (откуда мне знать, что вам непонятно?)
Ну оно так.
Да, инструкций много, и вполне понятные инструкции, но все же.
Хочу я по ssh удаленно управлять компьютером.
На обоих компьютерах стоит Linux
На одном Ubuntu, на втором Mint.
Вот я желаю с Ubuntu управлять Mint.
myr4ik07, правило №1
никаких ключей в каталогах в /etc/ прописано быть НЕ должно. Все ключи пишутся у юзеровПравило №2
Пара публичный/секретный ключ создаётся НА клиенте (там, ОТКУДА входите).Правило №3
Секретный ключ НИКОГДА не покидает своего места. Обычно он лежит в $HOME/.ssh/
(публичный имеет то же самое имя, но расширение .pub)Правило №4
Надо переносить ключ от клиента, к серверу. В домашний каталог КУДА вы входите, в конец файла $HOME/.ssh/authorized_keys
Да, инструкций много, и вполне понятные инструкции, но все же.
Хочу я по ssh удаленно управлять компьютером.
управляйте. Вышеотквочена инструкция. Какой пункт вам непонятен?
Да, первым делом усвойте терминологию:
Сервер - компьютер, который ждёт внешних сигналов.
Клиент - компьютер, который передаёт эти сигналы серверу.
Первым делом поправьте конфиг сервера так, что-бы там
1. не было никаких ссылок на ключи.
2. полный запрет на вход root'а
3. вход сначала по публичному ключу, потом по паролю.
Теперь попытайтесь войти с сервера на сервер (ага, тут сервер работает и как сервер, и одновременно работает другая программа - клиент)
ОК, теперь вы можете на сервере войти на сервер, причём только юзером, и только по паролю.
Теперь идите на клиент, и входите оттуда.
Далее, выходите с сервера, и если у вас есть каталог ~/.ssh - его стираете, что-бы не путаться. (ну или куда-нить переносите/переименовываете)
Теперь создаёте каталог ~/.ssh, заходите туда, и устанавливаете права
$ ssh-keygen -f key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in key.
Your public key has been saved in key.pub.
The key fingerprint is:
e4:46:89:a5:7e:2b:31:53:a5:a7:b0:cc:35:a6:e9:db doc@dt
The key's randomart image is:
+--[ RSA 2048]----+
| . . |
| + + |
| + X . |
| + % + |
| @ S |
| . * . |
| o . |
| + |
| . E |
+-----------------+спросят passphrase, это пароль для шифрования секретного ключа. Что-бы враг, взломавший клиент, не мог его использовать. Можно просто нажать ENTER, если вы хотите входить без passphrase.
Также покажут отпечаток пальца, в данном случае e4:46:89:a5:7e:2b:31:53:a5:a7:b0:cc:35:a6:e9:db, он нужен что-бы клиент был уверен, что враг не подменил сервер.
Его потом можно проверить:
Итак, мы создали пару ключей. Теперь переносим ПУБЛИЧНЫЙ (это важно) ключ на сервер.
Если машина доступна, и ходить вам не лениво, то key.pub можно перенести и на флешке (для врага он почти бесполезен, но всё равно его надо будет потом уничтожить с флешки). можно перенести и командой scp, или специальной утилитой
Теперь заходим на сервер, там мы удалили ~/.ssh, и создаём новый, и ставим его права (как на клиенте). Если каталог всё-же есть - проверяем права, и их исправляем. Также проверяем наличие и права файла ~/.ssh/authorized_keys, его права должны быть 0600.
Теперь добавим публичный ключ к ~/.ssh/authorized_keys
Возвращаемся на клиент, и проверяем - теперь входим уже без пароля.
Получаем права рута на сервере
Теперь проверяем работу с клиента. Если мы на клиенте (удалённо), то лучше не выходить - за ошибку не пустят. Потому откроем её одну консоль, и проверяем оттуда.
PS: все пункты надо выполнять точно и последовательно, но самое главное, необходимо ПОНИМАТЬ, что вы делаете.
Теперь идите на клиент, и входите оттуда.
Консоль:
$ ssh server_user@server_ip
вы должны войти по паролю. Если вы не вошли, значит ssh закрыт каким-то фильтром. Вам оно виднее.
И на этом остановлюсь, так как я не знаю, что блокирует вход по ssh и из-за этого топик и создал.
ssh ozone@localhostвход выполняется, а вот удаленно ни в какую.
Спасибо конечно, за столь подробную инструкцию, даже мне искать не потребуется, все что надо вы выложили, благодарю.
Но сначала нужно как то добиться удаленного входа по ssh.
Firewall никаким не пользовался, ну кроме iptables но я к нему не лез.
Вот мне и кажется, что нужно добавить пользователя ozone в группу, которая дает возможность входить через ssh. Но думаю вам лучше знать.
Жду дальнейших советов...
И на этом остановлюсь, так как я не знаю, что блокирует вход по ssh и из-за этого топик и создал.
ничего у вас не блокирует, вы-же сами видите:
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
А значит, дело не в этом.
Возможно, вы просто сами себе закрыли вход по паролю (это делать надо, но не сразу).
Покажите конфиг сервера
Вот мне и кажется, что нужно добавить пользователя ozone в группу, которая дает возможность входить через ssh. Но думаю вам лучше знать.
может и так... У Марка своеобразные представления о безопасности. Но в Debian'е я никого никуда не добавлял.
И да, системе в общем-то всё равно, удалённый вы юзер, или нет.
Рискну предположить, что клиент (а кто у нас клиент?) как-то не так запросы выдаёт. Например используя протокол 1 (он уязвим, и его запрещают, сейчас 2)
# 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 или настраивать PAM authentication нужным образом.
UsePAM no или настраивать PAM authentication нужным образом.
а что, разве в бубунте не sshd_config ???
этож какой-то толстый писец...
Lupo Alberto, кстати, в клиенте UsePAM yes, и всё работает. Значит и на сервере USEPAM yes. Локально-то работает! А удалённо UsePAM no. Следуя вашему совету, всё сломается 
Я вот тут подумал, у меня два компьютера в одной сети, то есть два компьютера подключены к одному роутеру и обращаясь за узнавание IP адреса компьютера, на примере http://2ip.ru/ меня осенило, а может быть не идентифицирует меня потому что я обращаюсь считайте на один и тот же адрес?!????
Видимо так 
P.S. У меня на двух компьютерах одинаковые глобальные IP адреса
Я вот тут подумал, у меня два компьютера в одной сети, то есть два компьютера подключены к одному роутеру и обращаясь за узнавание IP адреса компьютера, на примере http://2ip.ru/ меня осенило
а вы по внешнему IP что-ли заходили? :O
надо по внутреннему, обычно 192.168.1.2 и 192.168.1.3
а вы по внешнему IP что-ли заходили?
надо по внутреннему, обычно 192.168.1.2 и 192.168.1.3
Блин, ну да Вот капец, даже не пробуя уверен, что будет работать А если по внешнему то тоже должно бы работать? Или этот протокол только для локалки?
А если по внешнему то тоже должно бы работать? Или этот протокол только для локалки?
по умолчанию доступ снаружи внутрь закрыт в роутере. Что-бы всякие не шлялись.
1. Поставьте разные и другие порты (не 22) в конфиге сервера
2. пробросте порты в роуторе.
Это если надо снаружи входить. Но лучше так не делать конечно.
что там у вас по глобальному адресу - без понятия. От настроек роутера зависит на самом деле... Обычно там сам роутер. Туда тоже можно конектится, например что-бы залить прошивку. Но не везде по SSH.
1. Поставьте разные и другие порты (не 22) в конфиге сервера
Ага, с этим когда то я разбирался. В итоге у меня ничего не вышло, потому что серый IP адрес выделяется мне.
В итоге у меня ничего не вышло, потому что серый IP адрес выделяется мне.
вы можете использовать IPv6 туннель. http://version6.ru/why
вы можете использовать IPv6 туннель. http://version6.ru/why
Ух ты, не знал о таких достоинствах ipv6. Спасибо, с удовольствием прочитал, очень интересно.
Я и не думал, что такое уже можно осуществить.
Примусь к "раскуриванию" этой темы smile
P.S. Кстати, "дотяну" файлы с сети и попробую на локальный ssh зайти smile , а то чего то "ступил".
Я и не думал, что такое уже можно осуществить.
я тоже обрадовался - быстрый Ethernet у нас стОит как жутко медленный ADSL (отдача жалкие 512кбпс), но меня останавливало отсутствие IP нормального, и как следствие - удалённо не войти. А иногда очень хочется. Теперь у меня быстрый и дешёвый интернет smile
Примусь к "раскуриванию" этой темы
сначала потренируйтесь на кошкахв локалке.
Выполнив вход по локальному адресу
ssh ozone@192.168.1.2:22 вход был успешно произведен.
P.S. Не могли бы вы мне пример привести, да бы в следующий раз не создавать новый топи, как открыть доступ к ssh не с локального, а с глобального IP?
myr4ik07 пишет:В итоге у меня ничего не вышло, потому что серый IP адрес выделяется мне.
вы можете использовать IPv6 туннель. http://version6.ru/why
Почитав и сделав вывод, что оно так еще сыро.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Linux Forum → Ubuntu, Linux Mint → Добавить пользователя в группу SSH
Форум работает на PunBB, при поддержке Informer Technologies, Inc
