Здравствуйте, банальный вопрос, но, как добавить пользователя в группу, что бы через этого пользователя можно было удаленно заходить по протоколу ssh?
P.S.
Я на компьютер 1 поставил shh сервер, здесь у меня пользователь ozone
На компьютере 2 задаю команду ozone@23.434.11.91
ozone - единственная учетная запись компьютера 1
23.434.11.91 - это IP адрес компьютера 1
Появляется запрос на введения пароля но после ввода пароля, пользователя ozone компьютера 1 ничего не происходит.
LinuxForum.Fans
Добавить пользователя в группу SSH
Автор: myr4ik07
30 сообщений
8826 просмотров
myr4ik07, нужно смотреть настройки ssh-сервера, откуда и что разрешено.
На компьютере 2 задаю команду ozone@23.434.11.91
Нужно так:
text
ssh ozone@23.434.11.91
...хотя если вы имеете одинаковые учётные записи на обоих компьютерах, имя можно не указывать. Есть ли пользователь ozone на втором компьютере?
Добавьте в команду опцию -v, чтобы вывод в консоль стал подробнее и покажите его.
myr4ik07, нужно смотреть настройки ssh-сервера, откуда и что разрешено.
[quote=myr4ik07]На компьютере 2 задаю команду ozone@23.434.11.91
Нужно так:
text
ssh ozone@23.434.11.91
...хотя если вы имеете одинаковые учётные записи на обоих компьютерах, имя можно не указывать. Есть ли пользователь ozone на втором компьютере?
Добавьте в команду опцию -v, чтобы вывод в консоль стал подробнее и покажите его.[/quote]
Подскажите, в какой строке конфигурационного файла искать разрешенные данные?
Я забыл просто дописать ssh, я ввожу правильно команду.
text
ssh ozone@23.434.11.91P.S. У меня выходит так, на компьютере 1 есть учетная запись ozone
и на компьютере 2 есть учетная запись ozone
на обоих компьютерах учетная запись ozone с одинаковыми паролями
Не знаю, правильно ли "присобачил" параметр, но вывод вышел таков
text
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:
Добавлю еще вот это
text
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.
Вот содержимое файлика
text
# 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
Вы что-то (если не всё) делаете не так.
[quote=Lupo Alberto]Покажите файл /etc/ssh/ssh_config.
Вот содержимое файлика
text
# 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
[/quote]
По инструкции, которых много, пишется:
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. вход сначала по публичному ключу, потом по паролю.
Теперь попытайтесь войти с сервера на сервер (ага, тут сервер работает и как сервер, и одновременно работает другая программа - клиент)
[console]$ ssh localhost[/console]
Если вы уже создали пару ключей - войдёте без пароля, только с предупреждением о том, что вы входите на неизвестный сервер. Вам покажут отпечатки пальцев и IP. Отпечатки нужны для того, что враг может подделать сервер и его IP, и клиент придёт не туда. Ну в данном случае IP 127.0.0.1, это вы и есть.
Если вы ещё не создали ключи - попробуйте войти по паролю. Должно получится. Вообще говоря, если вы таки вошли без пароля, то вы ошиблись. Сотрите каталог ~/.ssh на сервере, что-бы не путаться.
ОК, теперь вы можете на сервере войти на сервер, причём только юзером, и только по паролю.
Теперь идите на клиент, и входите оттуда.
[console]$ ssh server_user@server_ip[/console]
вы должны войти по паролю. Если вы не вошли, значит ssh закрыт каким-то фильтром. Вам оно виднее.
Далее, выходите с сервера, и если у вас есть каталог ~/.ssh - его стираете, что-бы не путаться. (ну или куда-нить переносите/переименовываете)
Теперь создаёте каталог ~/.ssh, заходите туда, и устанавливаете права
[console]$ mkdir ~/.ssh
$ cd ~/.ssh
$ chmod 0700 .
[/console]Затем создаёте пару ключей
text
$ 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, он нужен что-бы клиент был уверен, что враг не подменил сервер.
Его потом можно проверить:
[console]$ ssh-keygen -l
Enter file in which the key is (/home/doc/.ssh/id_rsa): key.pub
2048 96:94:0a:e6:5a:f5:64:a3:db:aa:2e:99:0b:b8:bb:5d key.pub (RSA)
[/console]
обратите внимание, что я указал публичный key.pub, а не секретный key. У второго свой отпечаток, который нам обычно не нужен.
Итак, мы создали пару ключей. Теперь переносим ПУБЛИЧНЫЙ (это важно) ключ на сервер.
Если машина доступна, и ходить вам не лениво, то key.pub можно перенести и на флешке (для врага он почти бесполезен, но всё равно его надо будет потом уничтожить с флешки). можно перенести и командой scp, или специальной утилитой [console]ssh-copy-id[/console]
Теперь заходим на сервер, там мы удалили ~/.ssh, и создаём новый, и ставим его права (как на клиенте). Если каталог всё-же есть - проверяем права, и их исправляем. Также проверяем наличие и права файла ~/.ssh/authorized_keys, его права должны быть 0600.
Теперь добавим публичный ключ к ~/.ssh/authorized_keys
[console]$ cat key.pub >> ~/.ssh/authorized_keys[/console]
Если файла не существовало, то он создастся, и его права надо поставить в 0600.
Возвращаемся на клиент, и проверяем - теперь входим уже без пароля.
Получаем права рута на сервере
[console]$ su -[/console]
и правим конфиг так, что-бы
1. руту было не зайти.
2. вход только по ключу.
перезагружаем sshd. Если мы вошли удалённо, то командой stop мы остановим сервер, нас выкинет, и придётся тащится обратно к серверу. Потому останавливаем и запускаем сервер одной строкой, разделяя команды точкой с запятой (и ИМЕННО ей!)
Теперь проверяем работу с клиента. Если мы на клиенте (удалённо), то лучше не выходить - за ошибку не пустят. Потому откроем её одну консоль, и проверяем оттуда.
PS: все пункты надо выполнять точно и последовательно, но самое главное, необходимо ПОНИМАТЬ, что вы делаете.
Теперь идите на клиент, и входите оттуда.
Консоль:
$ ssh server_user@server_ip
вы должны войти по паролю. Если вы не вошли, значит ssh закрыт каким-то фильтром. Вам оно виднее.
И на этом остановлюсь, так как я не знаю, что блокирует вход по ssh и из-за этого топик и создал.
text
ssh ozone@localhost вход выполняется, а вот удаленно ни в какую.
Спасибо конечно, за столь подробную инструкцию, даже мне искать не потребуется, все что надо вы выложили, благодарю.
Но сначала нужно как то добиться удаленного входа по ssh.
Firewall никаким не пользовался, ну кроме iptables но я к нему не лез.
Вот мне и кажется, что нужно добавить пользователя ozone в группу, которая дает возможность входить через ssh. Но думаю вам лучше знать.
Жду дальнейших советов...
И на этом остановлюсь, так как я не знаю, что блокирует вход по ssh и из-за этого топик и создал.
ничего у вас не блокирует, вы-же сами видите:
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
А значит, дело не в этом.
Возможно, вы просто сами себе закрыли вход по паролю (это делать надо, но не сразу).
Покажите конфиг сервера
[console]$ sudo sed '/^#/d;/^$/d' /etc/ssh/sshd_config[/console]
(в дебе этот. Наверное в бубунте тоже самое)
(sed вырезает комментарии)
Вот мне и кажется, что нужно добавить пользователя 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. Следуя вашему совету, всё сломается :P
Я вот тут подумал, у меня два компьютера в одной сети, то есть два компьютера подключены к одному роутеру и обращаясь за узнавание IP адреса компьютера, на примере http://2ip.ru/ меня осенило, а может быть не идентифицирует меня потому что я обращаюсь считайте на один и тот же адрес?!????
Видимо так :)
P.S. У меня на двух компьютерах одинаковые глобальные IP адреса
Войдите или зарегистрируйтесь, чтобы ответить.
