Tag Info

New answers tagged

0

Your support people always connecting through that proxy machine, and only from it, so the clients could simply authenticate the proxy machine using HostbasedAuthentication. Let's say the proxy machine is supporters.pc and you provide support to customer.pc customer.pc will have HostbasedAuthentication yes in /etc/ssh/ssd_config, supporters.pc listed in ...


1

If you set up an SSH proxy server, you could arrange that your staff users' shell (in /etc/passwd) is not set to a shell such as bash, but instead to a simple script that doesn't allow shell access. Instead, it would ask for a target hostname (read target), then exec ssh "support@$target". Note that using a proxy like this might make it difficult to use ...


-1

One possibility is to create a user (say support-ssh) specifically for these outgoing SSH connections, then install a setuid copy of the ssh client a small wrapper binary that execs /usr/bin/ssh. Don't copy the ssh binary itself, because you won't remember to re-copy it every time you apply security updates. The wrapper binary should set HOME to the ...


9

What you really want to do is to use SSH CA and sign keys used by each support person (they should have their own ssh keys, like passports) and configure your clients' servers to use the TrustedUserCAKeys /etc/ssh/users_ca.pub in the /etc/ssh/sshd_config. This way the server will accept any key signed by the CA key (which you have access to) and you will be ...


5

I would suggest a couple of options. Protect the ssh key and require the use of sudo on your support team's side. You could do this transparently with a wrapper. Call the wrapper, say, /usr/local/bin/ssh-support and have it contain something like this (untested): #!/bin/bash export PATH=/usr/local/bin:/usr/bin:/bin export IFS=$' \t\n' # Restart if not ...


4

PUBKEY=$(cat ~/.ssh/id_rsa.pub); grep -q "$PUBKEY" ~/.ssh/authorized_keys || echo "$PUBKEY" >> ~/.ssh/authorized_keys This one-liner checks whether pubkey is already present in authorized_keys file, and appends it to the end of file if it is not present. ~/.ssh/id_rsa.pub here is path to pubkey being added ~/.ssh/authorized_keys here is a path to ...


3

Normally sshd does allow either public key authentication, password authentication and the others you have enabled. From your output you can see that GSSAPI is tried first, but that did not succeed. Next the public keys are offered but they were not accepted and finally the password authentication asks you for a password. If you enter a wrong password (or ...


0

The issue is solved. Turns out there were some issues with the firewall behind which the non-connecting client was sitting. After clearing these up, the client connects properly using pub key authentication


2

Doing a diff in both output I see this: They look kind of the same but one is doing different authentification, you should check the settings of your ssh server. One is doing md5 and the other one sha1, so check it out. Also, I don't know if you already know this but the clients are different. So to make an assumption of why one works and the other ...


2

OpenSSH public key format is different from PEM format. You have to run ssh-keygen to convert it. ssh-keygen -f ~/.ssh/id_rsa.pub -e -m PEM >pubkey.pem Then convert it to DER format using openssl rsa. openssl rsa -RSAPublicKey_in -in pubkey.pem -inform PEM -outform DER -out ~/.ssh/id_rsa.pub.der -RSAPublicKey_out Note that you also have to specify ...



Top 50 recent answers are included