SSH как root с использованием открытого ключа все еще запрашивает пароль на RHEL 6.1
Я сгенерировал ключи rsa с помощью cygwin ssh-keygen и скопировал их на сервер с помощью
ssh-copy-id -i id_rsa.pub root@my.ip.address
У меня есть следующие настройки в моем файле /etc/ssh/sshd_config
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin yes
Когда я ssh root@my.ip.address он по-прежнему запрашивает пароль.
Выход ниже из /usr/sbin/sshd -d говорит, что соответствующие ключи были найдены в файле.ssh/authorized_keys, но для него по-прежнему требуется пароль от клиента.
Я прочитал кучу сообщений о правах доступа к файлам и каталогам, но ничего не работает. Возможно ли ssh с ключами в RHEL 6.1 или это запрещено?
Отладочный вывод из ssh и sshd приведен ниже.
$ ssh -v root@my.ip.address
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Connecting to my.ip.address [my.ip.address] port 22.
debug1: Connection established.
debug1: identity file /home/dschulze/.ssh/id_rsa type 1
debug1: identity file /home/dschulze/.ssh/id_rsa-cert type -1
debug1: identity file /home/dschulze/.ssh/id_dsa type 2
debug1: identity file /home/dschulze/.ssh/id_dsa-cert type -1
debug1: identity file /home/dschulze/.ssh/id_ecdsa type -1
debug1: identity file /home/dschulze/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
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 9f:00:e0:1e:a2:cd:05:53:c8:21:d5:69:25:80:39:92
debug1: Host 'my.ip.address' is known and matches the RSA host key.
debug1: Found key in /home/dschulze/.ssh/known_hosts:3
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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/dschulze/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering DSA public key: /home/dschulze/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/dschulze/.ssh/id_ecdsa
debug1: Next authentication method: password
Вот вывод сервера из /usr/sbin/sshd -d
[root@ga2-lab .ssh]# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_5.3p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 172.60.254.24 port 53401
debug1: Client protocol version 2.0; client software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "root"
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "172.60.254.24"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: db:b3:b9:b1:c9:df:6d:e1:03:5b:57:d3:d9:c4:4e:5c
debug1: restore_uid: 0/0
Postponed publickey for root from 172.60.254.24 port 53401 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: db:b3:b9:b1:c9:df:6d:e1:03:5b:57:d3:d9:c4:4e:5c
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: do_pam_account: called
Accepted publickey for root from 172.60.254.24 port 53401 ssh2
debug1: monitor_child_preauth: root has been authenticated by privileged process
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support enabled
debug1: PAM: establishing credentials
PAM: pam_open_session(): Authentication failure
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/1
ssh_selinux_setup_pty: security_compute_relabel: Invalid argument
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 17323
debug1: session_exit_message: session 0 channel 0 pid 17323
debug1: session_exit_message: release channel 0
debug1: session_pty_cleanup: session 0 release /dev/pts/1
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Received disconnect from 172.60.254.24: 11: disconnected by user
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: deleting credentials
Вот содержимое /etc/pam.d/sshd:
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth
Вот вывод ls -lah .ssh
[root@ga2-lab ~]# ls -lah .ssh
total 12K
drwxr-xr-x. 2 root root 4.0K Dec 11 14:09 .
drwxr-xr-x. 3 root root 4.0K Dec 11 14:08 ..
-rw-------. 1 root root 399 Dec 11 14:09 authorized_keys
5 ответов
Я решил эту проблему, добавив другого пользователя, а затем изменив каталог webcat / Tomcat, чтобы он принадлежал этому обычному пользователю. У этого обычного пользователя нет проблем с аутентификацией с помощью ключей, и он может выполнять команды через ssh и scp (удаленное повторное развертывание в Tomcat).
Еще одна мера безопасности, предпринимаемая RHEL, - отключение приложения-менеджера Tomcat, чтобы я не мог удаленно развернуть его через менеджер Tomcat. (Я попытался добавить приложение менеджера обратно и настроить пользователей с правами администратора и менеджера, но приложение менеджера не запустилось).
У меня была такая же проблема после установки Gitlab 6.4 на RHEL 6.5. Что бы я ни делал, я не мог использовать SSH с открытыми ключами для основного пользователя системы (git). Опять же, ключи SSH были в порядке, как и разрешения для ~/.ssh (700) и ~/.ssh/authorized_keys (600). Проблема заключалась в том, что seliunx "приводил в исполнение", и контексты в каталоге.ssh были неправильными, возможно, потому, что пользователь был создан как системный пользователь. Вы можете исправить это, как @Dean-Schulze, изменив пользователя на обычного, но мне удалось исправить контексты для затронутого пользователя с помощью команды restorecon, которая может решить возникшую проблему.
Проверьте, работает ли selinux
sestatus
Изучите контексты, используя
ls -laZ ~/.ssh
Я обнаружил, что контекст "type" должен быть "ssh_home_t"
Чтобы исправить каталог ssh login / su как затронутый пользователь и затем запустить
restorecon -R -v ~/.ssh
Если это не сработает, вам может потребоваться исправить контекст в домашнем каталоге пользователей.
restorecon -R -v ~/
Больше информации я нашел полезной http://themattreid.com/wordpress/2012/11/02/selinux-solutions-fixing-a-newly-provisioned-server-that-refuses-ssh-key-based-login/
Отказ для ~./ Ssh выглядит следующим образом в /var/log/audit/audit.log:
type=AVC msg=audit(1355348670.326:87): avc: denied { read } for pid=1490 comm="sshd" name="authorized_keys" dev=dm-1 ino=277466 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
SELinux включен?
getenforce
Какой контекст в ~/.ssh? Это может быть неверно для созданного вручную каталога.
# ls -alZd .ssh/
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 .ssh/
Но должно быть после того, как вы сделаете релабель или установите соответствующий контекст.
# ls -alZd .ssh/
drwx------. root root system_u:object_r:ssh_home_t:s0 .ssh/
Или отключить SELinux / установить разрешающий:)
Неисправные открытые ключи обычно вызваны неправильными правами доступа к файлу Authorized_keys. Убедитесь, что он chmodded для 644.
У меня была эта "проблема" много раз. Проблема не только с разрешением файла авторизованных ключей, также должны быть правильно установлены права доступа к каталогам ".ssh" и ".." (домашний каталог пользователя). Проблемы могли бы быть решены путем установки разрешения следующим образом: от 700 до.ssh, по крайней мере от 754 до ".." и 600 до файла authorized_keys:
# ls -lah .ssh
drwx------. 2 root root 4.0K Dec 11 14:09 .
drwxr-xr--. 3 root root 4.0K Dec 11 14:08 ..
-rw-------. 1 root root 399 Dec 11 14:09 authorized_keys
Неисправные открытые ключи обычно вызваны неправильными правами доступа к файлам authorized_keys файл. Убедитесь, что он chmodded для 644:
chmod 644 /root/.ssh/authorized_keys
Если это не помогло, попробуйте проверить сообщения об ошибках в /var/log/secure файл на стороне сервера.
И, наконец, в вашем выводе есть подсказка, которая указывает, что SELinux может блокировать вещи:
ssh_selinux_setup_pty: security_compute_relabel: неверный аргумент
Для этого сообщения может быть объяснение в журнале SELinux: /var/log/audit/audit.log,