New shell server transition

[blakers]

Key based ssh is working. Make sure your permissions are not any more open than mine and make sure the name of your auth file is the same. There have been changes over the years, but what I show here is currently working:

$ ls -la .ssh/
total 24
drwx------. 1 dherr user 4096 Jun 30 2017 .
drwx------. 1 dherr user 4096 Apr 19 11:25 ..
-rw-------. 1 dherr user 1192 Jun 30 2017 authorized_keys
-rw-r--r--. 1 dherr user 204 Mar 27 17:42 known_hosts

Pubkey's working great (still) with 'oldshell'

With new 'sh.sonic.net', keyboard-interactive works find; pubkey, not.

Here's what I see:

Code: Select all

ssh -l myacct -o "PreferredAuthentications keyboard-interactive" sh.sonic.net
	Password:
	Last login: ... from ....lightspeed.snmtca.sbcglobal.net

	...
	ls -al .ssh
		drwx------. 1 myacct user 4096 Apr 19 13:55 .
		drwx------. 1 myacct user 4096 Apr 19 13:51 ..
		-rw-------. 1 myacct user  846 Apr 19 13:55 authorized_keys

	ssh -Q cipher
		3des-cbc
		blowfish-cbc
		cast128-cbc
		arcfour
		arcfour128
		arcfour256
		aes128-cbc
		aes192-cbc
		aes256-cbc
		[email protected]
		aes128-ctr
		aes192-ctr
		aes256-ctr
		[email protected]
		[email protected]
		[email protected]
	ssh -Q mac
		hmac-sha1
		hmac-sha1-96
		hmac-sha2-256
		hmac-sha2-512
		hmac-md5
		hmac-md5-96
		hmac-ripemd160
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
		[email protected]
	ssh -Q kex
		diffie-hellman-group1-sha1
		diffie-hellman-group14-sha1
		diffie-hellman-group14-sha256
		diffie-hellman-group16-sha512
		diffie-hellman-group18-sha512
		diffie-hellman-group-exchange-sha1
		diffie-hellman-group-exchange-sha256
		ecdh-sha2-nistp256
		ecdh-sha2-nistp384
		ecdh-sha2-nistp521
		curve25519-sha256
		[email protected]
		gss-gex-sha1-
		gss-group1-sha1-
		gss-group14-sha1-
	exit

locally, my ssh_config,

	Host sh.sonic.net
	User myacct
	HostKeyAlgorithms ssh-ed25519,ssh-rsa
	Ciphers       [email protected],aes128-cbc,[email protected],aes128-ctr
	MACs          [email protected],[email protected],hmac-md5,hmac-sha1
	KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group1-sha1

ssh -l myacct -o "PreferredAuthentications publickey" sh.sonic.net
	Permission denied (publickey,keyboard-interactive).


ssh -l myacct -o "PreferredAuthentications publickey" -v sh.sonic.net
	...
	debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
	debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
	debug1: Remote is NON-HPN aware
	debug1: Authenticating to sh.sonic.net:22 as 'myacct'
	debug1: SSH2_MSG_KEXINIT sent
	debug1: SSH2_MSG_KEXINIT received
	debug1: AUTH STATE IS 0
	debug1: kex: algorithm: [email protected]
	debug1: kex: host key algorithm: ssh-rsa
	debug1: REQUESTED ENC.NAME is '[email protected]'
	debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: [email protected]
	debug1: REQUESTED ENC.NAME is '[email protected]'
	debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: [email protected]
	debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
	debug1: Server host key: ssh-rsa SHA256:2...
	debug1: Host 'sh.sonic.net' is known and matches the RSA host key.
	debug1: Found key in /etc/ssh/ssh_known_hosts:31
	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,keyboard-interactive
	debug1: Next authentication method: publickey
	debug1: Trying private key: /etc/ssh/ssh.desk.ed25519
	debug1: Authentications that can continue: publickey,keyboard-interactive
	debug1: Offering RSA public key: /etc/ssh/ssh.desk.rsa
	debug1: Authentications that can continue: publickey,keyboard-interactive
	debug1: No more authentication methods to try.
	Permission denied (publickey,keyboard-interactive).

Am I missing the obvious here?

[tbessie]

On the new shell server, when I use Alpine to read my mail, it appears to be using different VIM settings than it does when I start VIM from the command line directly. That is, it doesn't appear to be honoring the .vimrc sitting in my home directory.

Have you configured Alpine to use a different .vimrc file?

- Tim

I have not -- haven't heard of this problem until now.

This is one reason we decided to swing the "shell" alias over, to uncover and fix more issues before we decommission the old l server.

-Scott
p.s. catching up on forum now...

No biggie - hope you're able to figure out why this happens.

- Tim

[scott]

For those who were asking (hi Marshall The new key fingerprints for sh.sonic.net are:

ECDSA key fingerprint is MD5:72:68:03:a1:6c:c3:48:5c:13:04:b7:4d:91:b3:5c:5d
ECDSA key fingerprint is SHA256:3Shjz0z7pf5EhaJuPaq4Dij92qFd34dRl9pbeNZAtWk

The following are all the key fingerprints, right from the public key files. Please note that the key fingerprint depends on which key you are using (ECDSA, ED25519, or RSA):

_[/etc/ssh]_(root@sh)_
# for II in *.pub ; do echo $II ; ssh-keygen -l -E MD5 -f $II ; ssh-keygen -l -E SHA256 -f $II ; done
ssh_host_ecdsa_key.pub
256 MD5:72:68:03:a1:6c:c3:48:5c:13:04:b7:4d:91:b3:5c:5d no comment (ECDSA)
256 SHA256:3Shjz0z7pf5EhaJuPaq4Dij92qFd34dRl9pbeNZAtWk no comment (ECDSA)
ssh_host_ed25519_key.pub
256 MD5:8d:c3:6d:72:39:df:89:a2:37:40:48:42:7a:d7:aa:23 no comment (ED25519)
256 SHA256:6tFAH1q7rLiOLdMAri5Qb1fZ9BPWE/Qf3L9x/t70NGQ no comment (ED25519)
ssh_host_rsa_key.pub
2048 MD5:44:ef:ed:17:07:d1:a9:83aa:43:a3:00:77:60:7e no comment (RSA)
2048 SHA256:2v/NEm+2VjOi7WV/W/BV42TG5D8rBYrHELsCVyEbciA no comment (RSA)

You may need to adjust your known_hosts file accordingly, if you've been using the address "shell.sonic.net" to connect.

[scott]

Key based ssh is working. Make sure your permissions are not any more open than mine and make sure the name of your auth file is the same. There have been changes over the years, but what I show here is currently working:

$ ls -la .ssh/
total 24
drwx------. 1 dherr user 4096 Jun 30 2017 .
drwx------. 1 dherr user 4096 Apr 19 11:25 ..
-rw-------. 1 dherr user 1192 Jun 30 2017 authorized_keys
-rw-r--r--. 1 dherr user 204 Mar 27 17:42 known_hosts

Pubkey's working great (still) with 'oldshell'

With new 'sh.sonic.net', keyboard-interactive works find; pubkey, not.

I'm not sure what the problem could be. Can you email the username that you replaced with "myacct" in your examples to [email protected] ? I'll need that to track down what's going on.

-Scott

[scott]

Key based ssh is working. Make sure your permissions are not any more open than mine and make sure the name of your auth file is the same. There have been changes over the years, but what I show here is currently working:

$ ls -la .ssh/
total 24
drwx------. 1 dherr user 4096 Jun 30 2017 .
drwx------. 1 dherr user 4096 Apr 19 11:25 ..
-rw-------. 1 dherr user 1192 Jun 30 2017 authorized_keys
-rw-r--r--. 1 dherr user 204 Mar 27 17:42 known_hosts

Pubkey's working great (still) with 'oldshell'

With new 'sh.sonic.net', keyboard-interactive works find; pubkey, not.

I'm not sure what the problem could be. Can you email the username that you replaced with "myacct" in your examples to [email protected] ? I'll need that to track down what's going on.

-Scott

Figured it out, I think.

Try this:

ssh -l myacct -o "PreferredAuthentications publickey,keyboard-interactive" sh.sonic.net

The reason you have to do it this way is a long story, so tl:dr: To make google authenticator work with public keys, we also need to tie into pam, which is handled through keyboard-interactive/pam. The pam config then bypasses asking for a password if you have already authenticated with publickey.

-Scott

[blakers]

Figured it out, I think.

Try this:

ssh -l myacct -o "PreferredAuthentications publickey,keyboard-interactive" sh.sonic.net

The reason you have to do it this way is a long story, so tl:dr: To make google authenticator work with public keys, we also need to tie into pam, which is handled through keyboard-interactive/pam. The pam config then bypasses asking for a password if you have already authenticated with publickey.

-Scott

that requires a password

Code: Select all

ssh -l myacct -o "PreferredAuthentications publickey,keyboard-interactive" sh.sonic.net
  Password:

The goal, of course, not having to USE the password, rather, the pubkey ...

[scott]

Pubkey's working great (still) with 'oldshell'

With new 'sh.sonic.net', keyboard-interactive works find; pubkey, not.

I'm not sure what the problem could be. Can you email the username that you replaced with "myacct" in your examples to [email protected] ? I'll need that to track down what's going on.

-Scott

Figured it out, I think.

Try this:

ssh -l myacct -o "PreferredAuthentications publickey,keyboard-interactive" sh.sonic.net

The reason you have to do it this way is a long story, so tl:dr: To make google authenticator work with public keys, we also need to tie into pam, which is handled through keyboard-interactive/pam. The pam config then bypasses asking for a password if you have already authenticated with publickey.

-Scott

Ooo, there's more too this, bbias.

Edit: Nope, works with ed25519 keypairs too.

So, as above: should work with the quoted command.

-Scott

[utilika]

Has Sonic changed the rules for SFTP connection to the shell without telling users? I just tried and failed to connect by using my previously working settings, and when that failed I checked the instructions again. Only after seeing this discussion, I tried again with sh. instead of shell., and it failed again with a key pair but succeeded with password authentication.

If the rules have changed, where are the new ones posted, and why not in the FTP FAQ?

[scott]

Has Sonic changed the rules for SFTP connection to the shell without telling users? I just tried and failed to connect by using my previously working settings, and when that failed I checked the instructions again. Only after seeing this discussion, I tried again with sh. instead of shell., and it failed again with a key pair but succeeded with password authentication.

If the rules have changed, where are the new ones posted, and why not in the FTP FAQ?

Rename your ~/.ssh/authorized_keys2 file to ~/.ssh/authorized_keys .

I will get that into the wiki page for Shell_Access. Had meant to do it earlier but got sidetracked. Sorry about that.

-Scott

[lr]

The home directly file system on the shell machine seems to have been eaten by a large monster. Not a huge crisis, no reason for me to call tech support on the phone, but someone needs to reach in there and clear the jam.