Hello,
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
I'd appreciate if any one can help.
Thanks,
Simon
On Fri, 2006-12-22 at 11:48 -0500, Simon Wu wrote:
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
What happens if you try to log in as a non-root user?
El Viernes, 22 de Diciembre de 2006 18:42, Tim escribió:
On Fri, 2006-12-22 at 11:48 -0500, Simon Wu wrote:
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
What happens if you try to log in as a non-root user?
Please, try also with -v -v -v and you would be able to find out where the problem is. Cheers
On 12/22/06, Manuel Arostegui Ramirez manuel@todo-linux.com wrote:
El Viernes, 22 de Diciembre de 2006 18:42, Tim escribió:
On Fri, 2006-12-22 at 11:48 -0500, Simon Wu wrote:
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
What happens if you try to log in as a non-root user?
Please, try also with -v -v -v and you would be able to find out where the problem is. Cheers
-- Manuel Arostegui Ramirez.
Thanks. But -v -v -v doesn't seem to tell much. After passwd sent, didn't get authentication success.
But using a local account, ssh is OK.
Simon debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/identity ((nil)) debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa (0x9ff70e0) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root@pcary1c4's password: debug3: packet_send2: adding 64 (len 55 padlen 9 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again. root@pcary1c4's password:
On 12/22/06, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2006-12-22 at 11:48 -0500, Simon Wu wrote:
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
What happens if you try to log in as a non-root user?
--
Not root works fine.
Thanks
Tim:
What happens if you try to log in as a non-root user?
Simon Wu:
Not root works fine.
You've got two choices:
1. Change the configuration to allow remote root login. You can do this by editing "/etc/ssh/sshd_config" (it's quite easy to spot what needs changing).
2. Log in as yourself, then "su -" to become the root user. This is actually a good configuration option, as far as security goes.
El Viernes, 22 de Diciembre de 2006 19:22, Tim escribió:
Tim:
What happens if you try to log in as a non-root user?
Simon Wu:
Not root works fine.
You've got two choices:
- Change the configuration to allow remote root login. You can do this
by editing "/etc/ssh/sshd_config" (it's quite easy to spot what needs changing).
Definetly, that's not a good idea at all.
On 12/22/06, Manuel Arostegui Ramirez manuel@todo-linux.com wrote:
El Viernes, 22 de Diciembre de 2006 19:22, Tim escribió:
Tim:
What happens if you try to log in as a non-root user?
Simon Wu:
Not root works fine.
You've got two choices:
- Change the configuration to allow remote root login. You can do this
by editing "/etc/ssh/sshd_config" (it's quite easy to spot what needs changing).
Definetly, that's not a good idea at all.
Here's something that I've always been curious about. I assume that the dangers of allowing root log-in are:
1. It's a user name that every linux system (except ubuntu) has, so all a hacker needs is the correct password in order to gain access, rather than the correct user name and password.
2. Once access is gained, there are no restrictions on what the user can do, as they are root.
However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly /impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
Also, right now I set up sudo so it doesn't prompt for passwords, so in effect, any user that logs in can become root. Is this very very bad as well?
One of the dangers of allowing root is that it has to check the password, so thats a potential security risk in that its work for the machine to do, so every attempt causes cpu usage, and if you have 1000 ssh attempts a second, thats alot of work for it to do... Another more valid risk is that many passwords can be easily guessed or are plain text. Newer passwd commands warn you about this, but many still do not. So if your password is "p@ssw0rd" its very likely to be found easily.
The BEST way to allow root access is through ssh keypairs, that way no password is involved!
- Donald Tripp dtripp@hawaii.edu ---------------------------------------------- HPC Systems Administrator High Performance Computing Center University of Hawai'i at Hilo 200 W. Kawili Street Hilo, Hawaii 96720 http://www.hpc.uhh.hawaii.edu
On Dec 22, 2006, at 9:34 AM, Dylan Semler wrote:
On 12/22/06, Manuel Arostegui Ramirez manuel@todo-linux.com wrote: El Viernes, 22 de Diciembre de 2006 19:22, Tim escribió:
Tim:
What happens if you try to log in as a non-root user?
Simon Wu:
Not root works fine.
You've got two choices:
- Change the configuration to allow remote root login. You can
do this
by editing "/etc/ssh/sshd_config" (it's quite easy to spot what
needs
changing).
Definetly, that's not a good idea at all.
Here's something that I've always been curious about. I assume that the dangers of allowing root log-in are:
- It's a user name that every linux system (except ubuntu) has,
so all a hacker needs is the correct password in order to gain access, rather than the correct user name and password.
- Once access is gained, there are no restrictions on what the
user can do, as they are root.
However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83 possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly / impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
Also, right now I set up sudo so it doesn't prompt for passwords, so in effect, any user that logs in can become root. Is this very very bad as well?
-- Dylan
Type faster. Use Dvorak: http://dvzine.org -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Dylan Semler wrote:
Here's something that I've always been curious about. I assume that the dangers of allowing root log-in are:
- It's a user name that every linux system (except ubuntu) has, so all
a hacker needs is the correct password in order to gain access, rather than the correct user name and password.
- Once access is gained, there are no restrictions on what the user
can do, as they are root.
However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83 possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly /impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
This was my question as well, but I want to up this a bit. I actually disallowed password authentication over SSH. I only allow root and only with a correct key. Obviously someone could steal my key. But the key is password protected, so they would have to steal my password too. Now, at this stage actually creating a separate account on my box, an account I will never use for anything except to do su - seems ridiculous. Mind you that I do not do anything on my servers that doesn't require root privileges.
But think of it this way: you see all those log files with people trying to GUESS usernames: fred, mary, joe, jane.... wouldn't it be better to NOT allow root access so they MUST guess your username as well as key, and password? Three phase authentication is always better than two!
- Donald Tripp dtripp@hawaii.edu ---------------------------------------------- HPC Systems Administrator High Performance Computing Center University of Hawai'i at Hilo 200 W. Kawili Street Hilo, Hawaii 96720 http://www.hpc.uhh.hawaii.edu
On Dec 22, 2006, at 11:00 AM, Dmitriy Kropivnitskiy wrote:
Dylan Semler wrote:
Here's something that I've always been curious about. I assume
that the
dangers of allowing root log-in are:
- It's a user name that every linux system (except ubuntu) has,
so all a hacker needs is the correct password in order to gain access, rather than the correct user name and password. 2. Once access is gained, there are no restrictions on what the user can do, as they are root. However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83 possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly / impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
This was my question as well, but I want to up this a bit. I actually disallowed password authentication over SSH. I only allow root and only with a correct key. Obviously someone could steal my key. But the key is password protected, so they would have to steal my password too. Now, at this stage actually creating a separate account on my box, an account I will never use for anything except to do su - seems ridiculous. Mind you that I do not do anything on my servers that doesn't require root privileges.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Donald Tripp wrote:
But think of it this way: you see all those log files with people trying to GUESS usernames: fred, mary, joe, jane.... wouldn't it be better to NOT allow root access so they MUST guess your username as well as key, and password? Three phase authentication is always better than two!
It is even better not to allow password login at all. If you use key pairs for authorization, then they have first get your private key, then guess your pass phrase for the key. If they manage that, then they can try to guess the root password, or a local exploit that will let them become root... (If they know enough to get your private key, I figure they already know the user name...)
Mikkel
Dylan Semler wrote:
...snip...
However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83 possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly /impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
That is not the larger danger. The larger danger is that someone will find and publish an exploit for ssh2 as root That did happen to ssh1, and is why you should never allow ssh1 protocol to the Internet, ESPECIALLY if you allow root logins. ssh1 is still supported (thankfully) for compatibility with older systems. It is not meant to be used otherwise.
In that case if you allow root logins from ssh an exploiter can access your system as root, even without password guessing.
It is always best to avoid those possibilities. Turn off ssh1 and root access via ssh. See my other post in this thread for how to:
Also, right now I set up sudo so it doesn't prompt for passwords, so in effect, any user that logs in can become root. Is this very very bad as well?
Once a person is on your system, its too late. Its only a minor inconvenience for the hacker when you disallow sudo, but I do it anyway.
It is most common for a hacker to install a 'root kit' instead. There are still several that will work. And on older systems ... well he can just pick one. :)
By allowing open sudo, maybe a bud of yours will install a root kit for fun when you though he was playing on your new PS3 in there. :)
"Dylan Semler" dylan.semler@gmail.com writes:
However, if you use an 8-digit password with capital and lowercase letters, numbers, and symbols, there are 8^( 26*2 + 10*2 + 20 ) = 8^92 = 1.21e83 possible passwords. Since ssh waits about a second after each incorrect password and there have been only 3.32e17 seconds in the history of the universe, it seems scritcly /impossible/ for a password to be guessed. So the risk must not be from password-bots. What is the risk then?
This calculation is only correct if and only if the letters and numbers are truly chosen with uniform distribution. In practice people tend to choose mostly from the easy to type letters. The result is a password that is composed of mostly easy to type letters with perhaps one or two uppers, numerics or punctuation. The search space for that is quite a bit smaller than the full 92^8 of your example. My gut feel is that it would be well below 26^8 because even of the lower case, many are chosen with the same probability.
Personally I don't believe folks should be using passwords for anything but local logins. For ssh a 1k-bit rsa key is going to be a fair bit stronger and one doesn't have to worry about foolish users that pick their wife's name or pet's name as the password.
-wolfgang
If you definitely need root login, you're best option is to set up access privileges to allow only root from specific IP addresses. Or, if you have two NICs setup two ssh daemons to handle regular users and root users from specific ips using iptables and sshd_config.
- Donald Tripp dtripp@hawaii.edu ---------------------------------------------- HPC Systems Administrator High Performance Computing Center University of Hawai'i at Hilo 200 W. Kawili Street Hilo, Hawaii 96720 http://www.hpc.uhh.hawaii.edu
On Dec 22, 2006, at 8:57 AM, Manuel Arostegui Ramirez wrote:
El Viernes, 22 de Diciembre de 2006 19:22, Tim escribió:
Tim:
What happens if you try to log in as a non-root user?
Simon Wu:
Not root works fine.
You've got two choices:
- Change the configuration to allow remote root login. You can
do this by editing "/etc/ssh/sshd_config" (it's quite easy to spot what needs changing).
Definetly, that's not a good idea at all.
-- Manuel Arostegui Ramirez.
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Simon Wu wrote:
Not root works fine.
Check your sshd_config file on the server for the PermitRootLogin value.
(I always disable root login altogether and all password based logins. I explicitly list the users I want to allow to login and then setup key based authentication. I sleep much better that way. :)
Simon Wu wrote:
Hello,
I tried ssh between two Fedora 3 PCs. It only works one way, the other way, I got the following error:
root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied, please try again. root@pcary21j's password: Permission denied (publickey,gssapi-with-mic,password). [root@pcary631 ~]# cd /etc/udev
I'd appreciate if any one can help.
Thanks,
Simon
It is common, and appropriate to turn off root access to ssh. This is done in the /etc/ssh/sshd_config file.
All comments in this file are the default values, and several should be changed:
#Protocol 2,1 should read: Protocol 2
#PermitRootLogin yes should read PermitRootLogin no
and this is probably your case on one system.
Also, it is common and appropriate to ADD a line to this file like:
AllowUsers fred wilma barney betty
This will prevent any mischief on user ids that get installed from broken rpms, or other software installs, that may leave system accounts open to attacks.
sudo is your friend.
Learn to NEVER remote login as root.
For all the UNIX/Linux administrators that I have worked with over the years since ssh became available (yes, there was a time before that!), the preferred practice is:
1. generate keys on your desktop -- Don't use passcodes if you want easy logins. Consult your corporate security guru if you have one. ssh-keygen -t rsa ssh-keygen -t dsa cd ~/.ssh cp id_rsa.pub authorized_keys cat id_dsa.pub >> authorized_keys
2. Copy those keys to all systems that you manage. cd ~ scp -rp .tcshrc .login .ssh target_host: (or whatever shell startups you might like, ie: .profile, .bashrc, etc.) enter your password for the remote system when asked for
From now on you can ssh to and scp to target_host without entering a passwd.
When the need arises to to manage target_host: ssh target_host sudo vi /etc/ssh/sshd_conf (for example)
This will leave a trace in the log files, and will be reported on that day's Logwatch. A very good thing when you have unexpected problems and notice a typo in the command on Logwatch reports. :)
It is a very rare occasion that requires root login to a remote system.
Good luck!
-
Dmitriy Kropivnitskiy -
Donald Tripp -
Dylan Semler -
Manuel Aróstegui -
Mikkel -
Phil Meyer -
Simon Wu -
Tim -
Todd Zullinger -
Wolfgang S. Rupprecht