Project

General

Profile

Actions
Copy link

Support #26935

closed

Sepia Lab Access Request

Added by Ben England over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
David Galloway
Category:
-
Target version:
-
% Done:

0%

Tags:
Reviewed:
Affected Versions:

Description

I'm making this request because my Sepia VPN access stopped working,
when I do: openvpn --config sepia/client.conf --verb 5
I get "WRRMon Aug 13 17:13:47 2018 us=649444 AUTH: Received control message: AUTH_FAILED"
Should I just apply for a new account or try to revive my old one?

1) Do you just need VPN access or will you also be running teuthology jobs?

I will be running teuthology jobs

2) Desired Username:

bengland

3) Alternate e-mail address(es) we can reach you at:

4) If you don't already have an established history of code contributions to Ceph, is there an existing community or core developer you've worked with who has reviewed your work and can vouch for your access request?

Patrick Donnelly, Mark Nelson - I'm looking to be able to run smallfile on Cephfs in teuthology.

If you answered "No" to # 4, please answer the following (paste directly below the question to keep indentation):

4a) Paste a link to a Blueprint or planning doc of yours that was reviewed at a Ceph Developer Monthly.

4b) Paste a link to an accepted pull request for a major patch or feature.

4c) If applicable, include a link to the current project (planning doc, dev branch, or pull request) that you are looking to test.

5) Paste your SSH public key(s) between the pre tags

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC93wGgyyQmTxa7f+BZcYPUapTH2N1mnV1ikl9nzJzHhgrtJ6pv00LhtH1HqGhvoqnqZjBD5XRAKyjMRcMBT5MYcXXep5RqZ9sJ6Xz8rHkBjfl/OOQUeZ/ZyG/Ksr1jpGraN2xtr
jQQzbqN1YvirCqfLk2exPvVeEk4CGnNybwKwCWob1uKV46ASrYeQK8pfHxrW7pTo+xdErHOvb7uumZm89/YisUJGicO1qSHBeuw1MxjhnD+fIcxHKWY5NNJ4qScW6a5AABk1JJsoHkh9IGCVaf/zJv8D3gil5SiM8LIBKaNa1fn6o
ObPl/Ky/wkiIo2gmUZawvAVA8iJnX9eUPl ben@bene-laptop

6) Paste your hashed VPN credentials between the pre tags (Format: user@hostname 22CharacterSalt 65CharacterHashedPassword)

bengland@bene-laptop k9r9q3li+6NP6KXW4YVlMQ fae30cf7d17340e0009dedc4b78188ec2cd5737e634ba16070088f7698b3654e

Actions
Copy link
 #1

Updated by David Galloway over 5 years ago

  • Status changed from New to In Progress
  • Assignee set to David Galloway

I added your new public key.

Can you paste the full output of the OpenVPN debug output to a pastebin somewhere so I can investigate?

Actions
Copy link
 #2

Updated by Ben England over 5 years ago

sorry I missed the e-mail saying you had responded. I specified that my ssh public key was ben@bene-laptop but it isn't anymore, I changed my username to bengland (to match kerberos ID for Red Hat). So Should I just start from the beginning and regenerate the cert secret etc.? Everything else seems to work ok.

Also, should I be running openvpn as root or from my user account? If it's from my user account that's the only way it would know to use ~bengland/.ssh/id-rsa* right?

[root@bene-laptop openvpn]# openvpn --config sepia.conf --verb 5
Fri Aug 31 08:16:36 2018 us=421545 Current Parameter Settings:
Fri Aug 31 08:16:36 2018 us=421577 config = 'sepia.conf'
Fri Aug 31 08:16:36 2018 us=421587 mode = 0
Fri Aug 31 08:16:36 2018 us=421594 persist_config = DISABLED
Fri Aug 31 08:16:36 2018 us=421600 persist_mode = 1
Fri Aug 31 08:16:36 2018 us=421607 show_ciphers = DISABLED
Fri Aug 31 08:16:36 2018 us=421614 show_digests = DISABLED
Fri Aug 31 08:16:36 2018 us=421620 show_engines = DISABLED
Fri Aug 31 08:16:36 2018 us=421627 genkey = DISABLED
Fri Aug 31 08:16:36 2018 us=421632 key_pass_file = '[UNDEF]'
Fri Aug 31 08:16:36 2018 us=421638 NOTE: --mute triggered...
Fri Aug 31 08:16:36 2018 us=421651 272 variation(s) on previous 10 message(s) suppressed by --mute
Fri Aug 31 08:16:36 2018 us=421658 OpenVPN 2.4.6 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 26 2018
Fri Aug 31 08:16:36 2018 us=421668 library versions: OpenSSL 1.1.0h-fips 27 Mar 2018, LZO 2.08
Fri Aug 31 08:16:36 2018 us=422175 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 31 08:16:36 2018 us=422190 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 31 08:16:36 2018 us=422196 LZO compression initializing
Fri Aug 31 08:16:36 2018 us=422244 Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Fri Aug 31 08:16:36 2018 us=477878 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Aug 31 08:16:36 2018 us=477984 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Fri Aug 31 08:16:36 2018 us=478010 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Fri Aug 31 08:16:36 2018 us=478045 TCP/UDP: Preserving recently used remote address: [AF_INET]8.43.84.129:1194
Fri Aug 31 08:16:36 2018 us=478153 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Aug 31 08:16:36 2018 us=478177 UDP link local: (not bound)
Fri Aug 31 08:16:36 2018 us=478202 UDP link remote: [AF_INET]8.43.84.129:1194
WRFri Aug 31 08:16:36 2018 us=524270 TLS: Initial packet from [AF_INET]8.43.84.129:1194, sid=0e1e6dee c8c838a6
WFri Aug 31 08:16:36 2018 us=524433 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
WRRFri Aug 31 08:16:36 2018 us=567264 VERIFY OK: depth=1, O=Redhat, CN=openvpnca-sepia
Fri Aug 31 08:16:36 2018 us=568038 VERIFY KU OK
Fri Aug 31 08:16:36 2018 us=568084 Validating certificate extended key usage
Fri Aug 31 08:16:36 2018 us=568124 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Aug 31 08:16:36 2018 us=568151 VERIFY EKU OK
Fri Aug 31 08:16:36 2018 us=568174 VERIFY OK: depth=0, O=Redhat, CN=openvpn-sepia
WRWRWRWFri Aug 31 08:16:37 2018 us=678602 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2432 bit RSA
Fri Aug 31 08:16:37 2018 us=678644 [openvpn-sepia] Peer Connection Initiated with [AF_INET]8.43.84.129:1194
Fri Aug 31 08:16:38 2018 us=850051 SENT CONTROL [openvpn-sepia]: 'PUSH_REQUEST' (status=1)
WRRFri Aug 31 08:16:38 2018 us=882911 AUTH: Received control message: AUTH_FAILED
Fri Aug 31 08:16:38 2018 us=883056 TCP/UDP: Closing socket
Fri Aug 31 08:16:38 2018 us=883106 SIGTERM[soft,auth-failure] received, process exiting

[root@bene-laptop openvpn]# cat /etc/openvpn/sepia.conf
script-security 1
client
remote vpn.sepia.ceph.com 1194
dev tun
remote-random
resolv-retry infinite
nobind
#user nobody
#group nogroup
persist-tun
persist-key
comp-lzo
verb 2
mute 10
remote-cert-tls server
tls-auth sepia/tlsauth 1
ca sepia/ca.crt
auth-user-pass sepia/secret

Actions
Copy link
 #3

Updated by David Galloway over 5 years ago

I'd recommend starting from scratch with regard to the VPN. Delete sepia.conf and the /etc/openvpn/sepia directory and start here: https://wiki.sepia.ceph.com/doku.php?id=vpnaccess#linux

Actions
Copy link
 #4

Updated by Ben England over 5 years ago

I did as you suggested, here's the new client output, which was obtained as follows:

[bengland@bene-laptop openvpn]$ sudo ./sepia/new-client bengland@bene-laptop
Please submit the following line to the OpenVPN admin:

bengland@bene-laptop ud1gWgoNggJTS7LQtPTZTA d3ebd084ce385cb450ce2f83c02dc66a1637dedbc7a8b191dab68acfc935af41

Look ok?

Actions
Copy link
 #5

Updated by David Galloway over 5 years ago

Looks good. I pushed the credential. Try connecting to the VPN now please.

Actions
Copy link
 #6

Updated by Ben England over 5 years ago

I was able to connect with openvpn, can ssh to teuthology.front.sepia.ceph.com. Thanks! However, sshd doesn't recognize my public key yet. From:

https://raw.githubusercontent.com/ceph/keys/master/ssh/bengland.pub

There are 2 public keys registered, the first one is no longer valid, and the second one is the one I want to use. The second one is in my ~/.ssh/id_rsa.pub . Can we get rid of the first one and use the second one ending in "eUPl"?

I know I know, the username isn't bengland, I did this wrong years ago and used the username "ben" instead of "bengland" when generating the public-private key pair, is this why it is rejected? No evidence of that below. If so I guess I'll have to generate another public-private keypair with the username bengland to match my account and kerberos username and do the whole thing over again including the VPN?

[bengland@bene-laptop ~]$ ssh -i ~/.ssh/id_rsa -v teuthology.front.sepia.ceph.com

OpenSSH_7.7p1, OpenSSL 1.1.0h-fips 27 Mar 2018
debug1: Reading configuration data /home/bengland/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for
debug1: Connecting to teuthology.front.sepia.ceph.com [172.21.0.51] port 22.
debug1: Connection established.
debug1: identity file /home/bengland/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/bengland/.ssh/id_rsa-cert type 1
debug1: Local version string SSH-2.0-OpenSSH_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH compat 0x04000000
debug1: Authenticating to teuthology.front.sepia.ceph.com:22 as 'bengland'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm:
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server>client cipher: MAC: <implicit> compression: none
debug1: kex: client->server cipher: MAC: <implicit> compression: none
debug1: kex: need=32 dh_need=32
debug1: kex: need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:wvZfQioWxS/hx3OBmj+HU9+zGTxUm4bGYvM1A5Ce3Zc
debug1: Host 'teuthology.front.sepia.ceph.com' is known and matches the ECDSA host key.
debug1: Found key in /home/bengland/.ssh/known_hosts:104
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:X4sk2LFJiC04lIBSBTN13LuBnmZG+cin5CAmOBtSDZ8 /home/bengland/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: RSA SHA256:dwAlMTZcCUgzDuBtxFko8I2tZ5zHZbBStd6pjL+MyGU /home/bengland/.ssh/id_rsa_perf
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
's password:

Actions
Copy link
 #7

Updated by David Galloway over 5 years ago

Ben England wrote:

I know I know, the username isn't bengland, I did this wrong years ago and used the username "ben" instead of "bengland" when generating the public-private key pair, is this why it is rejected?

Nope. That's my fault; I only held up half my end of the bargain initially. I (now) moved your user from the "VPN only" access group to the "SSH" access group. You should be able to ssh to teuthology.front.sepia.ceph.com now.

Actions
Copy link
 #8

Updated by Ben England over 5 years ago

all fixed I can ssh to teuthology.front.sepia.ceph.com now. Thx again!

Actions
Copy link
 #9

Updated by David Galloway over 5 years ago

  • Status changed from In Progress to Resolved
Actions
Copy link

Also available in: Atom PDF