Ok,
The sshd server is centos 6.6 all updated.
When I run.
[root@cent6-privacyiudeatest2 ~]# privacyidea-authorizedkeys root
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:79:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL connections to fail. For more information, see
Advanced Usage - urllib3 2.1.0 documentation.
InsecurePlatformWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
Advanced Usage - urllib3 2.1.0 documentation
InsecureRequestWarning)
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:79:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL connections to fail. For more information, see
Advanced Usage - urllib3 2.1.0 documentation.
InsecurePlatformWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
Advanced Usage - urllib3 2.1.0 documentation
InsecureRequestWarning)
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1kc3MAAACBAKrFC6uDvKclV5S5fcL+Ndv0hJVDJ5
olTPV+zwWmshjAUi/RY6DvKPlLXT6hYno/0O0pDdE3hMkgnAfb
FeCmtlk+nTnHOI43q0oQEdTsDQG2vfXK936hgjdHtqOEjXPSXJ
9rFx0b+9fEQd3MDxaObnbC9zupVjJVrBVSqbUHKmlVAAAAFQDC
N4lFVO8CIMv97/B1eVNvjOCH3QAAAIBkr3/gNsp8D4Nyhl1kMp
pLnAtmK/JpcRON3ROsy9OPz1mZGs5ZyuuwWtsxELIzVVcP7DBf
899bL16MOcNSgQ/ctOiqfG057CSK8Wco5YA/GU9Vvu29NuARjD
7f8/TP0M4uZc7hdBhJVGb+ucZwM4kBymF9LbfLDe1FBOAuVhXV
bgAAAIAyuSy9ZebBl4ixftv8Nf7LqiLr08PqnnDgj53vk+koDq
Q20AyR0Ej62A9WaPjAxvmsENAKqvfS9iPD4kZjbElNfQzvkPKJ
h5Y66SDeg3M/ZID0T5pBBA48TZ7Fruxl9vnYL/Fu/Vq+12KJF4
RyMSQe4mn8oHJma2VzepBRBpLt7Q==
---- END SSH2 PUBLIC KEY ----
How do I get rid of the errors?
also, here is the debug output when I try to connect via shared key from
another machine.
[root@cent6-privacyiudeatest2 ~]# /usr/sbin/sshd -p 22 -D -d
-e
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]=‘-p’
debug1:
rexec_argv[2]=‘22’
debug1:
rexec_argv[3]=‘-D’
debug1:
rexec_argv[4]=‘-d’
debug1:
rexec_argv[5]=‘-e’
Set /proc/self/oom_score_adj from 0 to
-1000
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: 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: inetd sockets after dupping: 3,
3
Connection from 192.168.101.86 port
4197
debug1: Client protocol version 2.0; client software version
nsssh2_5.0.0013 NetSarang Computer,
Inc.
debug1: no match: nsssh2_5.0.0013 NetSarang Computer,
Inc.
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-cbc hmac-sha1
none
debug1: kex: server->client aes128-cbc hmac-sha1
none
debug1: expecting
SSH2_MSG_KEXDH_INIT
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: PAM: setting PAM_RHOST to
“192.168.101.86”
debug1: PAM: setting PAM_TTY to “ssh”
debug1: userauth-request for user root service ssh-connection method
publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 99/99 (e=0/0)
debug1: restore_uid: 0/0
debug1: permanently_set_uid: 99/99
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:79:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL connections to fail. For more information, see
Advanced Usage - urllib3 2.1.0 documentation.
InsecurePlatformWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
Advanced Usage - urllib3 2.1.0 documentation
InsecureRequestWarning)
/usr/lib/python2.6/site-packages/requests/packages/urllib3/util/ssl_.py:79:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL connections to fail. For more information, see
Advanced Usage - urllib3 2.1.0 documentation.
InsecurePlatformWarning
/usr/lib/python2.6/site-packages/requests/packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
Advanced Usage - urllib3 2.1.0 documentation
InsecureRequestWarning)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: Could not open authorized keys ‘/root/.ssh/authorized_keys’: No
such file or directory
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: Could not open authorized keys ‘/root/.ssh/authorized_keys’: No
such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 192.168.101.86 port 4197 ssh2
Received disconnect from 192.168.101.86: 0:
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
I’m not seeing the public key here, only the errors from python.
Thanks,
ToddOn Sunday, April 12, 2015 at 11:24:58 AM UTC-7, Cornelius Kölbel wrote:
Hi Todd,
I realize I did not respond to the list.
Shame on me!
This is the answer to the originial mal.
Please see, if it helps you out!
Otherwise, please respond!
Kind regards
Cornelius
-------- Weitergeleitete Nachricht -------- Betreff: Re: [PrivacyIdea]
Problem SSH Key Management with PrivacyIdea and some cosmetic bugs +
questions Datum: Mon, 30 Mar 2015 11:05:58 +0200 Von: Cornelius Kölbel
corneliu...@netknights.it <javascript:> An: Der PCFreak
maili...@pcfreak.de <javascript:>
Hi Peter,
in fact you gave the step by step description.
Am 30.03.2015 um 10:02 schrieb Der PCFreak:
Hi all,
I am currently trying to use PrivacyIdea for SSH Keys.
I read Client machines — privacyIDEA 2.0 documentation
http://privacyidea.readthedocs.org/en/v2.1/machines/index.html
but somehow I cannot get it working.
What I did:
-
created a machine-resolver (HOSTS resolver)
Name: localresolver
Filename: /etc/mysshhosts
Content of /etc/mysshhosts
10.11.12.13 privacyidea01
-
created a passwd resolver
Resolver name: privacyidea01_passwd
File name: /etc/passwd
-
created a user resolver
Name: privacyidea01_passwd
pointing to privacyidea01_passwd ( passwdresolver )
-
Enrolled a ssh token
SSHK00005BD7 sshkey active adm@privacyidea01 0 adm
privacyidea01_passwd
-
Assigned token to machine
Tokens and Applications for machine 10.11.12.13
Serial Application Options
SSHK00005BD7 (sshkey) ssh User: adm
-
created /etc/privacyidea/authorizedkeyscommand
[Default]
url=https://10.110.180.51
admin=admin
password=changeme
nosslcheck=true
Hint: The nosslcheck parameter is not mentioned in the
documentation!
thx, I added this to the docs.
- Changed /etc/ssh/sshd_config and added AuthorizedKeysCommand and
AuthorizedKeysCommandUser
#AuthorizedKeysFile %h/.ssh/authorized_keys
AuthorizedKeysCommand privacyidea-authorizedkeys
- AuthorizedKeysCommandUser liadm*
-
Test with
privacyidea-authorizedkeys adm
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC5vIFudt5qUoQyPgrgjBbat/yCb4U+b…adm@
privacyidea01
! Seems ok !
-
Tried login with SSH and the corresponding private key
FAIL!
If you checked “privacyidea-authorizedkeys adm” successfully, the user
“adm” should be able to login.
If it fails, there is probably a problem with the identification of the
machine.
I.e. the machine comes with another IP, than you assigned the token to.
If you assigned the token to the machine 10.11.12.13, the ssh server
should also contact the privacyidea system with this IP.
You can check in the audit trail for the action
/machine/authitem.
This is the call, which fetches the ssh keys.
In the column “client” you can see, with which IP the ssh server contacted
the privacyIDEA system.
(If it is the same machine, it might get confused with localhost and the
actual IP.)
You could also take a look at /var/log/auth.log
It would be nice if someone could give me a detailed step-by-step advice
how to do it correctly
I also found something like this in an old (1.x) documentation for
/etc/privacyidea/authorizedkeyscommand
[Default]
url = https://your.privacyidea.server
admin = low_rights_admin
adminrealm = admin_realm
password = secret
and the information:
Please be sure to restrict the access rights of this file. In a
productive environment you should also
ensure, that the token administrator mentioned in this config file is
not allowed to perform any additional
task like deleteing or creating tokens.
Is this still needed to have proper security? How to crate a
low_rights_admin?
The problem here is, that the admin account given in
/etc/privacyidea/authorizedkeyscommand can also login to the UI and manage
many things.
Check it out!
So if you are afraid, that a root user on the ssh server should not be
able to manage privacyIDEA you need to define a second privacyIDEA admin.
For doing this you need to get familiar with the policies.
7.1. Admin policies — privacyIDEA 3.8 documentation
You should create a admin policy with all rights for your normal admin and
a policy with the only action “fetch_authentication_itmes”.
I also ran into the following problem which could be a bug or at least
cosemetic:
When managing Tokens, the Info field of an SSH-Token is very long so to be
able to see the buttons like
“DELETE” “DISABLE” “EDIT”… you have to find the scrollbar and move it
rightmost to be able to see and click the buttons.
You are so much right.
And honestly at the moment I am a bit uncertain how to design this.
If you have a good idea regarding this one, please drop me a note or file
an issue on github.
Kind regards
Cornelius
Thanks in advance
Kind regards
Peter aka PCFreak
–
You received this message because you are subscribed to the Google Groups
“privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to privacyidea...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/55190324.6030805%40pcfreak.de
https://groups.google.com/d/msgid/privacyidea/55190324.6030805%40pcfreak.de?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
–
Cornelius Kölbelcorneliu…@netknights.it <javascript:>
+49 151 2960 1417
NetKnights GmbHhttp://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798
Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel